specs

[Billy Tanksley]

> -----Original Message-----
> From:	RE01 Rice Brian T. EM2 [SMTP:BRice@vinson.navy.mil]
> Subject:	RE: specs
> 
> > > 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.
> 
	You're using an unusual definition, to say the least.  However,
as best as I understand it, your arrow system expresses all information
by means of arrows.

	If every arrow is implemented as a Lisp object (i.e. a list) and
if Lisp can make any Lisp object available for reference, then Lisp can
make any arrow available for reference.

> > 	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.
> 
	Understood.  The main problem, of course, is that justifying the
Arrow system is similar to justifying writing -- there's just too many
things that can be done with it.

> > > > 	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'.
> 
	But I'm not suggesting making Lisp be Lisp -- I'm suggesting
making Lisp implement your arrow system.  Or more accurately, I was
asking whether a Lisp list models an arrow with any reasonable effect.

	Actually, Lisp is named 'Lisp', not 'Sip' (symbol processor).
Lists are the big thing.

> > 	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.
> 
	Good.

> > 	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.)
> 
	Interfaces don't cross borders.  They are borders.

	I'm alternating between chuckling at the pretentiousness of
having computers deal with ontologies and amazement at the possibility
that you just might have a way to do it.

	If you can do it, it'll be one of the great steps in computer
science.  Remember back when Computer Science work was called "Data
Processing," and referred to as DP?  Now we've gone up a level, and
we're "Information Systems."  Once computers can examine ontology, they
could possibly be reasonably called "Knowledge Engines."  The next step
would be "Understanding Frameworks," and finally, "Wisdom Applicators"
(okay, I'm making up the second word of each future title).

	Exciting.  I'm not convinced, but I'm a human, not a robot; I
don't need to be convinced to be excited.  Oh, and I don't have to
disbelieve in something to laugh at it ;-).

> > 	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.
> 
	Evolving Algebras (Abstract State Machines) are reflective.

> error-catching: no errors, just placing the computation outside of a
> complelte theory.
> 
	_No errors_?  That's all you can say?  I don't believe this!
I'm at a loss for words...

	Do you mean that it's impossible to make errors while designing
a system using the arrow system?  Preposterous!

	How can I minimize my risk of slipping the schedule (or possibly
worse, shipping a bug) while using the Arrow system to build a giant
library database for a customer?

	Out of curiosity, what do you mean about placing a computation
outside of a theory?

> complexity and optimization:  Tunes-methodology and mathematical
> know-how.
> 
	Mathmaticians are no better than software engineers at handling
complexity.  I'm not asking whether your system will only be usable by
better people; that's not a useful question (and if it's the actual
answer, I want to avoid your system, because it's asking for trouble).

> 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.
> 
	Incremental development is a good answer to any of my questions,
really :-).  One problem with most mathematical models is that you have
to understand the whole system before you can start modelling (this is
not true for Abstract State Machines/Evolving Algebras, but
otherwise...).

> current compatible methods: (correct!!) interface definitions and
> modularity.  this syetm will live or die by the correctness of things
> like
> hardware-description structures.