specs

[Eric W. Biederman]

>>>>> "RB" == RE01 Rice Brian T EM2 <BRice@vinson.navy.mil> writes:

So I don't give any false impressions, let me say that at the moment I don't
have time to code, anything for tunes.   But I can commit to the effort it
will take to make tunes functional, organizationally.

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

Bad definition of object.  Whatever they are should be defined by
their properties, not by their implementation details (bytes???).

Hyperlink search problem?

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

Quite likely.  That needs some clarificationtion.
Clear definition of the grouping mechanism, but it's all tangled in
the rest of the paragraph.

No purpose specified for the grouping mechanism.

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

This is a better specification of object but still leaves a lot out.
Such as purpose.

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

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

RB> is this the kind of specification that you want?

It's getting there, but still way to general yet.
And it is far from complete.

An simple example:
At work we are given descriptions of output files that need to be
created from our database.  We are told the record size.
The starting and ending position of each field.
The way data should be represented in each field.
A description of what data should be placed in each field.


For your arrow language, we need.
A precise specification of exactly what is your arrow language.
A description of what each of the operators does, and some description
  as to why you picked what you did.
A description of how the arrow language can be used to make a complete
  system.
No implementation details except as hints.

I expect this to be a least a several page document, that will take
a little while to write.  
The specifications documents be what the talk between 
Rice, Tril, and Fare are mostly about.

This should break tunes down into 2 hard problems (implementation, and
specification) instead of 1 monster, problem.

Eric