It's a list! It's an array! No, it's...
dsc at swcp.com
Fri Dec 6 22:00:01 EST 2002
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
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
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
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
More information about the Use-livecode