Prism Rationale, Part 1

[RE01 Rice Brian T. EM2]

> Maybe not.  :)  I think Brian's Arrow language is fundamentally pretty
> simple.  That's part of its beauty.  What's difficult is the
> RAMIFICATIONS of the Arrow language... that, I don't understand.  I
> think, because the Arrow language is so simple, Brian confused a lot of
> folks by saying, "Here it is, very simple, now here's three pages of
> what it means."  People saw the three pages and thought it was all
> trying to define the language.

yes, that's what i've been trying to express.  i guess that it was confusing
in that sense.  thanks for clearing that up.

maybe this will help further.  i'll categorize my ideas into areas of
development effort.

the language is defined, as far as i'm concerned.  i shouldn't have to
restate it at this point.

these are some of the things which will be part of the 'ramifications' part
of the Arrow system, as opposed to defining the language:
	operators
	functions
	declarations
	iteration abstraction
	data-structures
	languages
	grammars
	context abstraction (i.e. domain abstraction?) and resulting
algebras and logics
	multiple logical systems for arrow diagrams (this definitely fits
into the higher-order theory category, but will be necessary for proofs,
'type-checking', etc.)
	a logical system for atomizing infinitary abstractions
	the natural number system, rationals, reals, groups, etc.
	defining the shape of a graph as a first-order entity

(in that approximate order)

the 'cross-cutting' scheme, which is crucial to achieving the Tunes hll
specifications, seems to me to be an inherent property of the system.  that
is, it is relatively trivial in the Arrow system to make statements about
parts of other statements.  this basically amounts to being able to make a
new object in the Arrow system by assembling ANY group of other arrows in
the world of arrows.  in other words, there is NO INFORMATION HIDING to an
arrow (as opposed to a user or a module) WITHIN the arrow system.  all
information in the Arrow system is available to an arrow.  we achieve
'reflection' by including enough information about the system so that it
encompasses it's own existence.  if anyone is still confused about this,
just say so and try to give me your best guess as to what i mean, so that i
can, by seeing evidence of your point of view, extend my explanation to your
point of view.

here's my wish list for the implementation of the heap environment (not a
suggestion, just a communicative gesture - a statement of opinion.)
	encoding multi-dimensional arrows as contiguous regions of memory
(i.e. a range of the address space is designated for the group, and added
information access the member arrow)
	a 'virtual heap system' whereby there exist references to arrows not
explicitly stored on the heap (in finite memory), but instead in special
contiguous memory regions which the environment (?) designates as
'different', for the express purpose of having the desired reference
generated procedurally, perhaps within the machine model's internal state
heap.  this falls into the category of a primitive reflection mechanism,
since it will allow infinitary logic systems (i.e. those whose ATOMS are
infinitary objects, not systems of infinite complexity) to access infinite
domains arrow by arrow.
	another primitive reflection mechanism whereby the finite-state
diagrams for binary, word (32-bit) size memory is identified with numbers
actually stored in memory.  i was considering the effects of this before,
but the Prism arguments have removed my doubts.
	defining a (finite?)-state abstract machine like the Java VM in
order to exercise primitive reflection capabilities.  (i.e. as a
proof-of-concept)
	"porting" the system, using reflection, to the bare hardware.  (this
is a long way off, of course.)


well, now it's time for some of you to ignore this post, while others watch
in slight confusion, and a few respond with the usual questions.  i'm ready
for the questions.