specs

[Billy Tanksley]

> -----Original Message-----
> From:	RE01 Rice Brian T. EM2 [SMTP:BRice@vinson.navy.mil]
> Subject:	RE: specs
> 
> > 	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.
> 
	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.

	Sounds to me as though with the addition of a visualization
system it would.  Good; this is the start of our implementation.

> 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.
> 
	Could you mention some of these solutions?

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

> > 	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.
> 
	Sorry about the sarcasm, BTW.  You're doing a great job
answering questions, and I really appreciate that.

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

> > 	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.
> 
	Let me rephrase that paragraph as a question, then, so that you
can answer it.

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

	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?

	The answers to these questions are worthy of at least one
doctoral dissertation each, so I can't expect a pat answer for each of
them.  Nonetheless, I need more than I have now.

	-Billy