specs

[RE01 Rice Brian T. EM2]

more specifics:

at one point of view, the system will be a big persistent heap of Self-like
objects, each with hyperlinks into other objects within.  what i mean by
object is a contiguous allocation of memory at fine-grain (byte-size,
maybe?) for the arrow pane specification and associated implicit
optimization information, as well as string identifiers to ease interface at
first.  the objects should be resizeable, and the garbage collection scheme
should probably not be implemented yet, in light of the hyperlink search
problem.

it's quite likely that at no point should arrows exist as single un-grouped
entities, even during instantiation of new information.  the grouping
mechanism will abstractly be a multi-dimensional arrow (read N-vector or
Lisp list. think of an arrow which zigzags through several nodes).  the
internal representation will probably not necessarily be a literal space
filled with arrows only.  the internal representation also might benefit
from information hiding in order to allow re-optimizing the object's
structure.  this suggests not using literal pointers for hyperlinks.

here's a "grab bag" list of things to include within objects:
*	representations of arrows themselves as {tail, head} pairs of short
unsigned pointers with reference to the object's address.
*	lists of incidence and / or co-incidence relation predicates that
result in a complete definition of the graph desired.
*	a group of pointers referring to objects within which exist arrows
that reference arrows in the current object.

the arrows within objects could be accessed via a data-structure notation,
like A.b, where A is the object's address within the heap, and b indexes the
arrow within that object.  the index could of course be implemented as the
"nth arrow found by a linear search through the object's internal arrow
space".

the problem of indexing infinitely-sized arrow groups would be solved via a
'virtual' index which simply refers to the number or key given to the
iteration mechanism which generates the arrow dynamically, perhaps leaving
its representation within the object for later reference or reconstruction.
this is obviously going to be a focus for the reflection development.

is this the kind of specification that you want?