specs

[Billy Tanksley]

> -----Original Message-----
> From:	RE01 Rice Brian T. EM2 [SMTP:BRice@vinson.navy.mil]
> Subject:	RE: specs
> 
> > I am afraid I can't agree on this :-(. The linear text based format
> is
> > just one way of representing the information. And to me it does not
> > matter. What matters is the semantics behind the syntax. I can
> imagine
> > an interface to Lisp which would enable you to handle "graphical"
> > items such as arrow instead of linear text. 
> 
> you have a good imagination, because that's NOT Lisp.  that's
> something
> else.  Lisp is based on symbols of text.  that's like stating that a
> diagram
> of a BASIC program makes a visual language.
> 
	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.

	BUT...

> > And in many domains, arrows are probably not the best to visualize
> > information. 
> 
> arrows are _not_ the user interface, and they are not a first-order
> visualization method.  instead, the structure of an arrow system would
> be
> the information presented, and this, although preferrably visual,
> would
> definitely _not_ be best displayed as arrows only, or even mostly
> arrows.
> 
	Agreed.

	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?

	If you don't have anything for this, the whole game just might
be up.  Arrows without infinite structures are just another visual
programming language, and one which can't be worked in directly anyhow.
Might as well call machine language our LLL.

> >     Brian> another thing is that some of the abstraction operators
> for
> >     Brian> which i'm developing explanations do a lot of
> >     Brian> 'cross-cutting' that would result in an overload of
> >     Brian> identifiers.  
> > Overloading of identifiers looks like a syntactical problem to me.
> And
> > I think I have already expressed my opinion on syntactical problems.
> :-)
> 
> NO.  you're completely missing the point.  i don't mean overloading
> operators as is done in current languages.  i refer to gargantuan
> symbol
> tables required by a Lisp evaluator to emulate this system.
> 
	What symbol tables?  Lists don't need symbols.  Lambda does, but
that's not something we mentioned.

> > Infinitary structures means infinite quantity of information. And
> this
> > is a problem anyway if you consider that we only have finite amunt
> of
> > memory. 
> 
> did i say STORE infinitary structures?  no.  i referred to reasoning
> about
> infinitary structures and postulating statements about their elements.
> 
	You're going to have to be a LOT clearer.  I never saw any
implication of that.

	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.

	I'm sorry, I'm going way off base in my cynicism.  What is your
method for "reasoning about infinitary structures and postulating
statements about their elements" without storing them?

	I really don't mean to be insulting, I'm trying very hard to see
some way of implementing this.  Right now I don't.

	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?

	-Billy