arrow-structure syntax

[RE01 Rice Brian T. EM2]

Just some corrections to my original post (which I hardly proof-read) as
well as some more thoughts on the subject:

The 'arrow' format should be {tail, head} instead of {head, tail}
(arbitrary, I know, but it might avoid some arguments).  The metaphor here,
of course, is that the 'head' is what is 'pointed to', which is arbitrary
due to the inversion operator.
That results in:
	Identity: {t, h} -> {t, h}  (obvious and almost trivial, but it will
be important later)
	Inversion: {t, h} -> {h, t}
	Combinator: {{t, x}, {x, h}} -> {t, h}.

The purpose of these operators, as parts of the implicit (for now) context,
is to allow for the generation of arrows by determinate methods, mostly
automatically.  Otherwise, we would have to create such arrows probably very
frequently.  This gives a way to formulize an arrow-specification.  It also
is probably the only basis that we need for the 'evaluator' aspect of the
c-program, given some extensions to the operator set, of course.  But then,
we're intending on reflecting on the context of the system, so maybe this
point of view isn't quite enough.

Speaking of which, some ideas about operator add-ons are:
	modus ponens (inference)
	lambda (function-abstraction)
	mu (i'm still trying to find a good short description)
	pi (path)

I also tend to use the word 'graph' and 'multigraph' when intending to mean
'directed graph' and 'directed multigraph', respectively.  Of course, I was
referring to arrow-structures, so you probably had already guessed that. :)

There is also a question I stumbled on while looking at a simulation I was
doing in my head.  It seems that the possibility of an arrow pointing to a
group of arrows is a bit confusing to the system itself unless we add
something.  The idea that I had about using LISP style linked lists (made of
arrows, that is) to form a structure denoting a group results in some
confusion about how that group is denoted.  Maybe this will clarify:

	Let's say that I have some arrows that we'll assume are arbitrarily
related, or not related at all.  We want some arrow to point to the group in
a way that can't be confused with pointing to an arrow.  My initial idea is,
knowing the number of arrows that we want, to generate a structure of (n+1)
arrows forming the LISP linked-list, with each arrow's head pointing to the
'next' arrow, and the tail pointing to the arrow in the list's 'slot'.  The
final arrow's head, of course, points at NUL.  Notice that the arrow's head
would point at the next _arrow_, and not at its _tail_, as happens in the
usual graph.  The point is that in order to distinguish structures like this
from the landscape, especially as we might (would we?) want to have a
structure which resembles the union of this 'linked list' and its 'contents'
as a single structure.  Maybe, though, even if we _do_ want such a
structure, it could simply be placed itself in a 'linked list'.  Otherwise
(or perhaps in addition), we should make the distinguishment by including
such 'linked lists' as structures themselves included as part of the
reflective development process.  I could imagine, say, an infinite
linked-list prototype (template) or something existing _virtually_ to which
isomorphisms could be encoded (via arrows, of course).  I'll have to think
more on this.  There is also a paradox (maybe not undesirable) if we try to
encode the structure of a linked list by grouping them by another linked
list which in turn...  :)   There is also the notion of how to distinguish
the arrow intended to point to the linked-list from the list itself, since
it points to the 'successor' arrow just like the others in the list.  In the
confused situation, what the arrow's tail points to would be considered the
first element in the list, and arrows which point to that arrow would only
worsen things.
	Another way to look at it is to try to virtualize this structure
before the first bootstrap for the purpose of simplifying the interface.  On
the other hand, perhaps the same effect could be achieved by raising the
system to the level of 'pointer abstraction' before the first bootstrap so
that the naturally huge structures potentially needed could exist only
virtually without causing confusion over referencing formats.  After all,
keeping track of huge arrow-structures created on the fly with numerical
addressing seems to be an unnecessary headache.
	And here's _another_ view on the situation:  Take the idea of a
linked-list and the isomorphism it has with a binary tree, one consisting of
arrows and nodes with the leafs being the indexed arrows.  I'm not sure if
this would improve the situation at all, and in fact the only interesting
part of it is the mapping itself to the original linked list, and the
possibility of basing it on the lambda operator or something.  more later on
that...
	However, all of these methods seem only to be quick fixes which
themselves will be replaced once infinitary structures come into place.