specs

[RE01 Rice Brian T. EM2]

[reply to Bill Tanksley]

		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.

yes,  i admit that such a system would allow a Lisp emulation of a finite
group of arrows.  however, i believe that there are properties of the arrow
system as it tries to encompass information systems that will make finite
systems less than adequate.

		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.

ok.  i agree about the fact that Lisp can deal with finite groups of arrows.
however, this would comprise only a fragment of a full arrow system.  in
other words, we could write "arrow modules" using Lisp, maybe, but the
entire system (i am beginning to realize) will probably need some support
for dealing with the infinitary structures.  i don't know if Lisp can handle
it, or how to make it work that way, even if it can.

	Interfaces don't cross borders.  They are borders.

right, but the borders that i want the interface to bridge are not the ones
inherent in itself, but instead the borders in the representation of objects
_by_ the system to the external system (a generalization of a user and an
infinite state device like a networked system).

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

don't get too easily convinced.  i appreciate having someone call me a
charlatan any day of the week, until i'm sure that i have the answers.

	> primary difference from other mathematical models: it's
reflective.
	> 
		Evolving Algebras (Abstract State Machines) are reflective.

i have to admit that i haven't looked at them in particular.  are they a
category or a generalization of finite-state machines or what exactly?
(keep in mind that i thrive on exact definitions.  btw, i'll look it up on
the web as soon as i get the chance.)  in other words, how do you modify an
existing familiar system to come up with these evolving algebras?  maybe
it's a dynamic model theory (i.e. one where models are updated and
downdated, based on information received)?

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

sorry.  i jumped into another subject head-first, so to speak.  here's an
explanation (hold on, it's a bumpy ride.)

what i mean is that there is a certain kind of ontology for homo-iconizing
the split ontology of "what i want to do" versus "errors".  such is the sort
used to deal with paradoxes.  basically, if you assume an ontology with
access to the current context and an algebra for relating contexts, then an
'error' is just a piece of information which the user selects for a
context-escape.  the specific example of this is the exception.  the word
'exception' itself illustrates how the mind usually deals with this
situation: via a solution at the control-flow node of optimizing the
'common' control path and including the 'uncommon' error-handler path with
little care.  such is logical, and a plausible convex linear problem's
solution (i.e. optimize the common case to minimize overall time over
hundreds of runs through that control-flow node).
the general case which i am interested in is related to the concept in BETA
of integrating the idea of an 'exception' with the common 'pattern'
ontology, so that in cases where the context-escape is _not_ the unusual
case, the compiler can successfully understand the situation and optimize
the execution paths accordingly.

i simply intend for error-handling to be placed in the larger domain of
context-algebra, so that a 'divide by 0' is not an error, but an operation
returning, say, the _set_ of real numbers, for instance (this assumes a real
numbers' context).  it seems more appropriate in the arrow system to not shy
away from problems like this, but instead give the computer some sort of
reasoning scheme to make sense of the 'error', instead of passing the
address of the operation, which is the usual solution which is entirely
unhelpful for the user.  this usual solution yields minimal information,
which would constitute a non-repentant program in our system.

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

i agree, but we should include interfaces for mathematicians, linguists, and
others to write modules which the system can study and integrate into its
compilation system, for instance.