specs

[RE01 Rice Brian T. EM2]

> 	That's simply and utterly false.  A Lisp program is a Lisp
> program no matter what its user interface.  I was trying to kind whether
> Lisp lists fit the general idea of arrows, and aside from infinital
> structures they appear to.  It appears to me that Lisp would be a decent
> implementation language, AFAIK.
> 
yes, but Lisp doesn't make all invocations available for reference, which a
text-based version of Lisp would find very difficult to handle.  and i don't
think that there exists a visual language which uses the idea that the Arrow
system uses in this respect.  you MAY be able to imagine it, but it
introduces problems and solutions that no one has considered yet. that is
why it is different.

> 	I also have a worry about infinital structures of arrows -- how
> can they be represented?  It seems to me that any method we use of
> representing (single or finite numbers of) arrows will have to have an
> exception to allow it to represent these, due to limitations of finite
> space. Do you have any general guidelines for how this would be
> implemented?  Any ideas?
> 
we could axiomatically specify how to generate a given infinitary system,
and a separate analysis program should be able to recognize its cardinal
order (i.e. how large it is).  i'm working on solving that as we speak.

> 	What symbol tables?  Lists don't need symbols.  Lambda does, but
> that's not something we mentioned.
> 
once again, i was totally unclear.  i'm talking about 

> 	Well, if all we have to do is reason about general infinitary
> structures without necesarily storing them, then all we need to complete
> the arrow system is an entire system for deciding undecidable problems.
> You're right, once we have a complete arrow system we WILL be able to
> solve the halting problem.  That's wonderful -- it means that all those
> difficult math proofs can be solved by this system in time short of
> exponential.
> 
not exactly. the system just needs to know how to classify things into
'deciders' and 'non-deciders' of undecidable problems.  it needs to know
that the production of software code only will never solve an unsolvable
problem, and that effort should be directed towards giving information to
the user or some similar interface, like a group of users on an
internet-like system.

> 	There's another barrier aside from implementation that I don't
> see how to break (for myself).  I just don't understand what makes this
> arrow system in any way special.  It looks like just another visual
> programming language, and an immensely complicated (and theoretical) one
> at that.  It can express anything, including mistakes, and doesn't seem
> to have a way of catching those mistakes.  It would bring a whole new
> meaning to the words "spaghetti code."  Isn't software engineering
> complicated enough?
> 
this system just brings every piece of discrete knowledge into its fold.
that necessarily means that we'll have to ask questions which we thought
were ignorable earlier.  it just happens that i think that those are exactly
the questions which we should be asking.