specs

[RE01 Rice Brian T. EM2]

> > yes, but Lisp doesn't make all invocations available for reference,
> > which a
> > text-based version of Lisp would find very difficult to handle.
> > 
> 	I'm not sure what an 'invocation' is -- presumably it's a
> request from one thing to use some resource, or possibly it's the
> transaction which results from that request.  Either way, Lisp can make
> all invocations _within a model_ available for reference at least as
> easily as any other language.  I'm not claiming that Lisp IS your arrow
> system; I'm only asking whether a Lisp-style list completely implements
> an arrow.  If it does, then we'll use it to implement the basic arrow.
> 
hmm..  invocation would be the entire information content of a program,
piece by piece.  that is, all the structure that differentiates it from an
empty program.

> 	Could you mention some of these solutions?
> 
i don't know yet, really.  i've been working on that for a while.  the
interesting solutions would relate mostly to 'cross-cutting'.  i'll be ready
to talk about it soon.

> > 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.
> > 
> 	But this isn't a special property of the arrow system -- ANY
> finite system that can do more than count (I think that a PDA would be
> sufficient) can be set up to recognise and parse confepts like that.
> That doesn't make it more than finite, though.  In fact, it could be
> less than a Turing machine (not saying that about your arrow system).
> 
> 
> 
> > > 	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 
> > 
> 	Huh?
> 
sorry, i was forced to stop using the computer for a while.
i was going to say that Lisp needs identifiers to 'be Lisp'.

> > 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.
> > 
> 	That does sound useful, although not remarkably special.
> 
well, hopefully this will be merely a property of the final system, and not
a 'hack' as it is in current systems.  the point is that such reasoning in
our knowledge-reflective system will be used everywhere.  i'll clarify
further soon.

> 	What makes this Arrow system special?  How is it different from
> any other visual programming language?  How can it help us reason about
> problems?  What subset of all possible problems can it solve or express
> (e.g. Turing machines -> R.E. languages, PDAs -> context-independant
> languages, FSMs -> regular expressions).
> 
other visual programming systems don't have interfaces designed to cross
ontological borders (and i've reviewed a lot of them.  yes it should provide
more than sufficient material for a dissertation.)
as for problem reasoning, the use of encapsulating axiomatic systems should
provide us with the ammunition to reduce problems to equivalence classes
with transformations.
all of the problems that you mentioned should easily be within its scope.

> 	What makes this Arrow system special?  How is it different from
> any other mathematical model of computation?  How does it handle error
> catching?  How does it handle complexity and optimization?  How would we
> implement simple solutions to simple problems in it?  What currently
> known methods of software engineering would work well together with it?
> 
primary difference from other mathematical models: it's reflective.
error-catching: no errors, just placing the computation outside of a
complelte theory.
complexity and optimization:  Tunes-methodology and mathematical know-how.
simple solutions to simple problems: wait for an answer. i intend to show
how the arrow system will fully support this as a property of its
incremental-development support.
current compatible methods: (correct!!) interface definitions and
modularity.  this syetm will live or die by the correctness of things like
hardware-description structures.