Arrow road-map

Brian Rice water@tunes.org
Sun Jun 17 20:28:01 2001


Hello again.

Here's a rough outline of where I will start calling minor version 
numbers. When all of this stuff gets done, I'll update 0.X to 1.0 
following lots of bug-testing.

0.1
We're there. Lazy graph framework is there, composition, application, 
etc. are all lazy enough. Distinction of concrete and abstract 
arrows, basic frames, the Smalltalk MOP works in a very basic sense 
for immutable objects and literals.

0.2
The intension framework. This will likely not take up much code 
space, but result in a few refactorings, possible one or two new 
classes, and make frame assertions possible to interact in. Frame 
assertions (see AssertionGraph and ArrowFrame comments) will likely 
be the location for the basic pattern-matching mechanisms.

0.3
The interactive evaluator. This requires the implementation and usage 
of Dictionary-like (mappings from symbols to values - environments) 
graphs embedded into frames. The evaluator will use SEXP syntax and 
arrow semantics. If it's easily feasible, recursive embedding of 
environments will be implemented. Other issues may come up about this 
part of the design at that time or later: this can be re-designed a 
few times if needed. It may or may not be encoded within arrows and 
frames from the beginning, but self-hosting is an eventual goal for 
obvious reasons. There already are a Lisp interpreter and a Prolog 
interpreter to work from, as well as LIBRA. What will remain is the 
re-use of pattern-matching syntax schemes from other languages (I 
have a book or two on this plus a few language implementations to 
look through if needed.) This also requires a quotation mechanism for 
obvious reasons, but I am considering the possibility of general 
isomorphism and homomorphism support by graph specification.

0.4
Expansion of the frame design to support frame modification and 
operations on frames, hopefully in a non-resource-wasteful way. See 
the notions behind Maude's module system for the inspiration for this 
design goal.

Beyond that, I don't have a distinct order to introduce features in. 
I'm experimenting with a morphic UI package called connectors for a 
GUI-based interaction UI, using transparent and opaque panes and 
layout algorithms to visualize graphs, but in general it's a 
difficult task to layout arbitrary graphs usefully. So, expect 
perhaps a 0.5 through 0.7 at least for GUI implementation. I will try 
as much as possible to make the system equally comprehensible at the 
command line and on the bitmap display.

I will introduce all code changes as incremental ChangeSet files 
(.cs) to be applied sequentially. Each file will receive an index 
number and will include issue-specific code perhaps spread over 
several classes. Any class initialization methods in Smalltalk 
ChangeSets are automatically executed upon importation, so look there 
for code activity. All ChangeSets will be time-stamped, commented, 
and signed (by me at first, since I don't know of any other 
Smalltalkers who know enough about Arrow, but then bug-fixes are 
bug-fixes. Who knows.)

Each minor release point will have its own condensed and combined 
ChangeSet, to make things easier for you to use. At some point the 
Project file will likely not be as useful as the other documentation 
(obviously none of the documentation is good enough yet.)

Comments, questions, complaints, suggestions?
~