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