180 lines
7.3 KiB
Plaintext
180 lines
7.3 KiB
Plaintext
Date: Tue, 14 Jul 1998 19:35:41 +0900
|
|
To: zzdev@xanadu.net
|
|
From: Ted Nelson <ted@xanadu.net>
|
|
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.
|
|
|
|
|