Date: Tue, 14 Jul 1998 19:35:41 +0900 To: zzdev@xanadu.net From: Ted Nelson Subject: :zz: ZigZag Design Notes: SLICE LOGIC 1 (d6 Cc: ted zzSliceLogic.d6 98.07.14 [illustration accompanying this email: zzSliceLogic.bmp] SLICE LOGIC 1 The main objective of the ZigZag Slice system is to be able to combine pieces of zzstructure. Relatively fixed material (ends of rows, ends of columns, titles) are expected to stay in RAM, with other stuff coming and going. Further objectives: - to limit RAM usage without going to some system of virtual memory - to allow the user to select the portions being worked on - to allow slices to slide into the middle of other slices according to the user's desire. (Thus slices should be connectable anywhere, even in the middle of ranks.) MANY logics and rule-sets are possible for this. I have thought about this for some years. What follows is the simplest method I could work out that does the job neatly. It is called "Slice Logic 1" because it's the easy one that I think we should implement first. (Last week I produced a document with a more complex system, possibly for implementation later, and quite interesting technically-- I think-- but I want you to see this one first.) This system need not be implemented all at once. For instance, we can forbid Part II at first. - - - - - PART 0. SKIP ON FIRST READING. 0000. (If a rank has a leading edge, it cannot be a ringrank and necessarily has a trailing edge.) 000. ASSUME that the user can neatly divide the world into slices. Slices, like dimensions, may have any names, but with a prefix: slices begin with "s.". Lexical order thereafter will be significant. 00. There may be a d.slice and d.slicelist, not discussed here. (Eventually-- or now if there is a need-- the list of slices can be maintained along d.slice, and the cells of a slice can be connected on a list in d.slicelist. Still under consideration.) - - - - - PART I. PREFLET LOGIC. 0. A ZigZag slice is a data set with cells which may be connected to each other in the ordinary ZZ way. But not necessarily; there may also be loose cells in the slice. 1. Slice 0 (s.0) is always resident. Other slices may be called in as needed. 2. Slices are independent structures. CONNECTIONS BETWEEN SLICES ARE NOT OF THE USUAL KIND, with doubly-linked cells. Instead, they have *preferred* points of attachment. 3. PREFERENCE OF ATTACHMENT IS EXPRESSED BY MEANS OF A 'PREFLET'-- a piece of information in the cell specifying a cell in another slice to which it would *like* to be attached, negward, in a specified dimension. In the current design, a cell may have only one preflet in a given dimension. 4. The process of resolving preflets determines the way in which the slices are attached. However, once attached, the slices are stitched together doubly-linked in RAM somehow as ordinary zzcells. (Implementation is not significant; eventually different slices should be storable by different databases or other methods.) 5. When a slice is brought in, only the preflets of its leading edge-- all the negend cells-- are considered. (This could be done thusly: test all cells to see if they are negends; test all negends for preflets.) 6. Any cell with a preflet for a cell already resident, and not contested by any other cell's preflet, gets to insert/attach itself to the specified cell. 7. If a cell has a preflet for a cell which is not currently resident, the preflet is ignored. 8. Two cells may have to be separated to honor a preflet specifying one of them. These two cells will rejoin when the slice is swapped out, if appropriate. IF THEY HAVE A LOCKED LINK (not yet implemented), they may not be separated. 9. If two leading cells in two slices both have a preflet for the same cell in another slice which is resident, the slice with lower lexical order wins-- and the second slice attaches itself *indirectly*, to the trailing edge (posend) of the winning cell's rank. See illustration. 10. If two leading cells in the same slice A have a preflet for the same cell in a second slice B which is resident, the slice with lexically lower cellname wins-- and the second slice attaches itself *indirectly*, to the trailing edge (posend) of the winning cell's rank. See illustration. (This would probably lead to the two ranks in A later becoming a single rank, due to rule 12.) 11. Whenever a slice is swapped in or out, the preflets of all current slices must be resolved again. 12. Whenever a slice is swapped out, its detached negends are given preflets again. These preflets will normally be to the cells from which the cell has just been detached in s.0-- either directly or indirectly. 13. If swapping a slice out severs a rank in some other slice (usually s.0), that rank is reconnected where the swapped-out cells have just been taken away. (This will re-attach cells which were separated by the incoming slice, unless they have been moved.) - - - - - EXAMPLE. Consider the illustration. Assume that the x-axis is d.1 and the y-axis is d.2. Not shown is s.0, which contains cells 16, 42, 131, 265 and 22. These are not necessarily negends. Shown are two slices, s.2 and s.4. They have leading-edge preflets for some of the same cells in s.0. The preflets for 13 and 22 take effect without conflict. What follows is about resolving the others. Both s.2 and s.4 have a leading-edge preflet in d.2 for cell 16. s.0 wins. The cell in s.4 with a preflet for 16 connects to the *trailing* edge of the same rank in s.2 (cell 68). Similarly, both slices share a preflet for cell 42 in d.2. s.2 wins, and s.4 connects to the trailing cell in the same rank, cell 4. Similarly, both slices share a preflet for cell 265 in d.1. s.2 wins, and s.4 connects to the trailing cell in the same rank, cell 31. If s.2 is swapped out, preflets are considered again at the leading edges of all slices (except s.0). Thus s.4's preflets for 16, 42 and 265 then cause them to be directly attached to 16, 42 and 265. If s.4 is then swapped out, each rank of s.4 which is extracted from within a rank in s.0 causes that rank in s.0 to be reconnected. - - - - - PART TWO: CROSSING OF CELLS BETWEEN SLICES. (May be disallowed in Phase 1.) 13. (The user somehow knows where the slice boundaries are.) 14. If a cell is moved / hopped / connected into a different slice, and has *no* other connections to its former slice, all its contents are moved. The information that travels with it includes its contents, processor of origin, cell of origin, and which slice the cell of origin is on. 15. If a cell is moved / hopped / connected / cloned into a different slice, and retains connections to its former slice, a Remote Clone is made. The information that travels with it includes its contents, processor of origin, cell of origin, and which slice the cell of origin is on. 16. When a cell is swapped in, Remote Clones must be resolved. If a Remote Clone's connections in all slices are consistent with each other, it is considered to be one with its origin, and they are shown as only one cell. However, if they are inconsistent-- more than one connection posward or negative in a given dimension-- the second instance is deemed to be a clone. After each operation its connections should be checked for compressibility to one cell.