It's a list! It's an array! No, it's...

[Dar Scott]

On Thursday, December 5, 2002, at 03:46 PM, J. Landman Gay wrote:

> Next, of course, we'll want to know just what it is you are doing 
> exactly. ;)

I'm tinkering with a library that would help me in handling bundled up 
Revolution values.  I would like to make this available to the 
Revolution community when the right time comes.  I'm not sure exactly 
what that means and I'm open ot ideas.

Here is a tease:

I am using the terms "node" and "node sequence", the same or similar to 
what Monte suggested.  The question is still open; there might be an 
overwhelming fondness for "gaggle" among Revolutionaries.

Data can be wrapped to become a node.  A node can be unwrapped to get 
the data back.  The process is transparent for all values including 
every-day strings, binary strings, internal numbers and arrays.  
(Optional compromises increase the speed, but can't handle special 
cases.)  There might be a few holes.

Nodes can be chained together to form a node sequence.  A node is a node 
sequence of length one.  The value that a node wraps around can be a 
node sequence.  This can be nested indefinitely.

These are explicitly made known to the user:  The empty node sequence is 
the Revolution empty.  Node sequences are concatenated with the 
Revolution operator &.

Node sequences can be chunked just as characters or lines can be.  You 
can refer to a single node in a node sequence or to a range.  The 
indexes you use work just the same as those for the chunks you are used 
to.  So, if you might use "line 5 to -2 of myList", then in the node 
world you can think "node 5 to -2 of myNodeSeq" and write 
"nodeOf(myNodeSeq, 5, -2)" or something like that.  Just as it costs a 
little in time to access lines that are not near the front or back of a 
list, it costs a little to access nodes not near the front or back of a 
node sequence.

You can find the type of node and even add types beyond the built-in 
ones for both leaf types and node sequences.

If the analogy to chunks is helpful, I'll try to continue along that 
way.  I don't have the cool Revolution syntax, though.  I have to use 
functions and commands.  I'm open to suggestions for what function or 
functions would be appropriate to represent these example node "chunks":

       node 5 to -1 of mySeq
       node 3 of mySeq
       node 1 of mySeq

I can use node() & unNode(), node() & value(), valToNode() & 
nodeToVal(), wrap() & unwrap() or some other pair to wrap and unwrap 
data to make or break open nodes.  I'm not sure which.  Maybe there can 
be a value prefix in the name of the chunk function to pull the value 
from the chunk.

Would node equivalents of these chunk-like expressions below be handy?

       delete node 2 to 8 of mySeq
       put <nodeSeqExpression> into node -7 to -1 of mySeq

These would have to be defined as handlers and will not have the pretty 
syntax.

Maybe there can be some functions to help in this kind of thing:

       repeat for each node n in mySeq

With certain options set or with certain assumptions, node sequences are 
actually (somewhat) readable, making debugging easier.  One can easily 
make a pretty printer for them, too.

Node sequences can be stored to files or transmitted to other programs.  
They can be put into array elements.  They can be nested.  They can be 
passed as parameters and returned as function results.  With certain 
options set, they can be put into fields and removed without loss of 
data.  If small enough, they can probably be property values.  If small 
enough and with certain options set, they can be passed as 
null-terminated strings to externals and returned from externals.  I see 
no reason why they can't be copied and pasted, especially in 2.0.  I'll 
run experiments on nodes and stdin/stdout and on "open process for 
update".  Maybe objects can be flattened to node sequences.

Packing and unpacking arrays in general is a little expensive to get 
right and best for I/O or other rare times, but for other uses node 
sequences are handy for adding structure where arrays don't work out.  
An example is nesting.  Arrays are better for larger tables of data 
especially for random access.

Node sequences can work for simple structures or records.  You would use 
them the same way you would interpret a list as a structure.  Set a 
constant for each node number.  For example, if you have a structure 
that always has 7 nodes, then assign names to 1, 2, 3, 4, -3, -2, -1.  
You can then refer to each by name.  (This is not unique to nodes, you 
can do this with lines or items, too.  With nodes you can have large 
documents, numbers and images as values, though.)

You can also use node sequences for stacks, queues and other interesting 
sequential collections.  (As you can with lists.)  If you enjoyed lisp, 
you can use node sequences as lisp lists.  CONS, CAR and CDR away.

What makes nodes most especially useful to me is the ability to keep up 
with binary data and to package up data and move it around.  Arrays may 
have binary element values, I think, but lack nesting and are harder to 
ship off or store as files.

Node Sequences do not share data.  They do not use global arrays.  Each 
value is simply a string underneath and is independent of all others.  
You cannot have recursive data structures.  Only under certain 
circumstances can you mutalate values; the method encourages a 
functional approach.

This will be the first Revolution library to leave my desk.

I welcome comments now and when this is at a point where people can try 
it.

Dar Scott