The state of the art for Arrow specs (clarifications and addi tions)

[btanksley@hifn.com]

> From: Brian Rice [mailto:water@tscnet.com]
> Subject: RE: The state of the art for Arrow specs (clarifications and
> additions)

> Bill Tanksley wrote:
> >Okay, this makes sense.  May I assume that 'reified' means 
> >'having a car and
> >cdr which was inserted into the appropriate graphs'?  Or 
> >does it have a
> >definition which is external to this little essay?  If so, 
> >it might reduce
> >confusion to link to that definition, or at least mention the fact.

> Well, in general, 'reifying' arrows usually means putting an 
> arrow object
> onto the heap so that a running computation can refer to it.  
> It's a basic
> system service to be able to construct any member of any 
> graph, so that
> graphs are *the* means to defining objects constructively.

In other words, "reified arrow" is a tautology -- all arrows are reified
(from this point of view).  Even the arrows in the car-graph are reified.

If this is the case, perhaps your essay will become clearer if you remove
all reference to 'reification' and such.  Not everyone knows Latin.

> >(0) reified arrow: this type of arrow can be manipulated in 
> >several ways by
> >the system.  In particular, it has a "car" and "cdr" defined 
> >in terms of the
> >system.

> In that case, every arrow besides the ones that the user adds 
> are reified
> arrows.  But it is true of every arrow that it has a "car" and "cdr".
> That's why those graphs are part of the vm specification.

Wait.  "Besides the ones that the user adds."  Hmm.  So the user...  Um...
Sorry, by brain just short-circuited.

Okay...

Okay, I still don't get it.  You speak of "adding" non-reified arrows.
Obviously such arrows are not available on the heap (according to your own
words), so you can't mean adding them to the heap.  What are you adding them
to?

> >Oh, a question: is there any special reason why an arrow may 
> >only be reified
> >or unreified?  What if it was added to the car-graph but not to the
> >cdr-graph?

> Reification just allows you to have an object that the system 
> rules allow.
> In arrow, because the amount of objects allowed to exist by 
> the rules is
> unbounded, object allocation must be lazy.  So, 'reify' is 
> really about
> implementation, and not semantics.

I think that almost makes sense.  In other words, all arrows are on the
heap, official objects; reified arrows are arrows which HAVE to be
represented on the system graphs.

If this is correct, I would definitely remove discussion of reification from
this level of the paper.  You can start talking about it when people start
threatening optimization, but discussing it here seems to be premature
optimization.

> >> For example, if a meta-graph is treated as a function,

> >New word alert!

> Darn it, it's in the paper (just like "graph").

If I were you, I would have people read a short paper like this before they
read a big, academic paper.  Even if this is second-most-important,
interested people are going to be reading this paper to gain clarity on
confusing concepts.  If you regularly use words which are private to you,
those people are not going to find this useful.

> You just 
> take the graph as
> a set, and sketch the "is an element of" relation as another 
> graph.  What
> results locally is a central node representing the graph itself, with
> arrows radiating from it to it's members.

Oh!  In other words, meta-graphs are graphs which are _implied_ by the
structure of another graph.  They may or may not exist as actual arrows, but
the system can make them exist if needed.  Either way, the information is
implicit in the graph.

> I hope the statement above clarifies it.  Most likely, I 
> should include the
> meta-graph generation ability as a system primitive that 
> addresses graph
> functionality, but it's not clear how it fits in with the 
> whole design.

Yes, this makes sense.

> 	-Brian

-Billy