specs

[RE01 Rice Brian T. EM2]

> 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.
> 
this basically 'limits' our system to a Self-like system, although many of
the arrow groups that we would be concerned about are things like the group
of all arrows (i know, i know- the Russell's Paradox references), as well as
groupings which can be virtualized and calculated based on analyzing large
groups of arrows (or groups of groups (of ...)) lazily or using the
memory-management scheme to group the objects via addressing locality.
these kind of schemes should allow us to transcend the Self idea quite
easily.

another idea is to allow objects to use other objects' arrows in a
'first-order' way, which is of course the idea behind hyperlinks.  this
introduces a quite difficult problem of how to manage the locating of arrows
within the system, but of course identical pointers in our system at any
point should reference identical arrows.  This also suggests that as part of
the hyperlink management system that hyperlinks could refer to hyperlinks
(and so forth) which could form a shape of hyperlinks with _the_ arrow at
some central point.

> 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.
> 
*	an operational definition of the graph, using state-machine diagrams
and iteration on transitions.  this would say things like "if you follow the
arrows labelled a,b,c, and d then you will wind up at the same place, i.e.
they compose into identity or something like that.

> 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".
> 
we could also use an alternate implementation, such as one which uses the
index of the postulated arrows described by incidence / co-incidence
relational description.

> 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.
> 
strictly speaking, of course, the iteration mechanism would not be in the
object itself, in order to retain semantic cleanness by identifying objects
with exactly one meaning (abstract meaning, that is).