[Fwd: Re: Arrow System -- Rationale?]

[RE01 Rice Brian T. EM2]

before i begin, in order to clarify these discussions as they condense into
recipes in terms of arrows, i'll posit a standard for terminology.  we can
call a multi-dimensional arrow which does not reference itself as a <graph>,
and distinguish finite / infinite, etc. form that reference.   we'll
positively indicate when we want to make a <graph>, and we'll use a symbol
for it (uppercase).  we'll say <node> when we mean that from our current
perspective (i.e. within the current graph), there is no head or tail to the
arrow in question.  when we need to be vague because we don't know what the
node is like, we'll use the word <object>, which suggests possible, but
imprecise, internal structure.

> You throw around words like "requirements,"
> > "information," and "statements," but you don't say how these things
> > are
> > represented in Arrow, or (if there's no "one true way") give any
> > examples of how they might be.
> 	There isn't really any one true way -- it's all relative to the
> context.  This is one reason why I'm having such a hard time with the
> Arrow system.  Brian says (correctly) that the basic system is simple,
> but the problem is that the basic system isn't complete, and I'm not
> sure how much else we'll need in order to even be able to *model*
> problems using arrows, much less execute solutions.
> 
well, the statements that we would want to make in the system should no
doubt take some format that we choose (syntax trees with symbol-flow graphs,
like discussed earlier).  the point is that having done that, we should (and
would want to) write the specification for the machine which does this in
some other statements, perhaps in a format independent (not necessarily
different) from the original format.

> > Okay, so how do you represent a finite-state machine in the arrow
> > system?
> > 
> 	Any way you want to.  BUT, if you want the machine to DO
> anything, you have to build a FSM interpreter.  I have NO idea how we're
> going to make the FSM interpreter do anything -- perhaps we'll build an
> FSM interpreter interpreter.
> 
ok, just for reference, the graph for a finite-state machine is as such:
states are nodes, and transitions are arrows between the nodes.  the FSM is
a strict directed multi-graph (no reflexivity allowed unless we decide later
on that such is useful).  the FSM will be extensible, in that we should be
able to use a FSM to define a more detailed FSM by 'splitting' a state into
more finely differentiated 'substates'.  i'm not sure how to do this
exactly, but it seems reasonable.  we should also be able to generalize a
FSM by adding more dimensions to the 'state-vector' of our machine, and
create a new FSM to which a mapping identifies old states with new states.
i'm suggesting an idea for extending a FSM.

hopefully, with infinitary / iteration notations, we should be able to
extend our FSM's into more general state-machines (SM's?), such as machines
with unlimited stack sizes.

i was thinking more along the lines of having the state-machine interpreter
defined similarly.  i've recently been looking at the Eli compiler-compiler,
particularly at its specification of a Pascal machine and the resulting
implementation which it produces.  considering the low-level nature of
pre-processed C, i was surprised at the results.
on the other hand, i can appreciate the concern that you have about how to
'make' the Arrow system DO something, and have been churning some thoughts
in my head about such problems for quite some time.  it relates to
information updates, and i will have much more to say soon.

> > > really, the natural numbers and all 
> > > will be objects in the arrow system as well.
> > 
> > Do you mean that an arrow's slot can point to either an arrow OR an
> > object (natural numbers, etc)?  If that's what you're saying, I think
> > you're polluting the purity of the system somewhat.
> > 
> 	He was very, very unclear there.  He intends to have arrows be
> used to model/represent everything.
> 
to Jim Little:  sort of.  what i think that i want to say is that there will
be arrow structures for all concepts, including the natural numbers.  that
would _not_ suggest necessarily that the natural numbers themselves would be
some identifiable collection of arrows, merely that the system as a whole
effectively handles the concept of natural numbers (once again, i give you
more vague rhetoric).  this _obviously_ does not give you a recipe for
'making' the natural numbers in the system.  what we are looking for are an
expression of iteration, sums, inverses (for differences) and multiplication
(iterations of iterations).  then we simply identify the object to which
these relate to form the natural number system.

> > Either way, I'd like to see a solid example answering my question.
> > Show
> > me the money!  Or at least, "00".  Actually, make it (binary) "10",
> > since that demonstrates both of the binary digits.
> > 
> 	Okay.  "10" is represented by the absence of an arrow.  It takes
> up zero storage and can be computed instantly.  It's so quick because
> there is only one alternative -- that means that there are zero bits of
> information needed to be communicated.  If you wanted me to represent a
> single bit in a number of different contexts, I might do it by pointing
> an arrow from the context where you wanted the bit to either another
> arrow or nothing.
> 
hehe.. billy's been into lazy compilers :).  well, jim is obviously looking
for something which i believe category theory (in arrow logic, categorial
grammar) answers quite easily.  we simply represent an ordered pair of
oriented binary state containers, yielding our 'data type', and represent a
selection via a mapping from a collection of two objects (nodes, from this
perspective) to each of the states of the two containers.