New Project Coordinator Introduction

[RE01 Rice Brian T. EM2]

> My guess is that once a moderately complete set of speces is written
> it will take roughly a year for tunes to materialize from thin air.
> I have seen many people willing to do it, come and go from this list,
> but they never stay because they don't know what to do.
really? wow.
> Please theoreticians specs specs specs.  
> Specs that say which invariants must be maintained to defined a
> reflective system.
> 
fine.  you want specs for tunes?  i can live with this.

what i can't give you is the spec for reflection in general.  i CAN,
however, give you a spec on the prototype arrow system i have in mind which
IS reflective and easily syntax-independent at that.  it handles hardware
descriptions (or machine-model descriptions) via finite-state machines.  it
handles user-interface via infinite-state machines.  it exceeds
lambda-abstractions.  it allows explicit encoding of grouping and patterns
to encode primitive reflection and aspect orientation.  i can use it to
specify a formal grammar for a programming language (i.e. interface) and
then use an algorithm in arrows to implement it on whatever virtual machine
that i desire.  i also know for certain that the system can emulate Self,
ML, Lisp/Scheme, Forth, and Oberon quite simply.  because of a concept i
call "shape factorization", i expect to be able to develop a portable module
specification language with a high information density while retaining the
distributability of the code.

and i can build an arrow system incrementally WITHOUT the actual prototype
running due to the easy ability to model the system on paper, and then use
the results to write up formal descriptions in a custom-made format (just
your standard EBNF grammar-defined language).

the arrow language is the ML, the HLL, and the LLL.  it can implement O'TOP,
C translation, general distributed semantics, and general interface
semantics.  it's DECIDABLE, and can be used to reason about other languages
and language fragments, so that you can always quickly find out what sort of
interface you're jumping into.

it doesn't have to be orthogonally persistent: that's a feature.  (helpful,
though).
it doesn't have to be fault-intolerant or bug-free: that's another feature.

it needs lots of optimizations, but i'm already working on ideas for those.
most of them involve decorating the arrow panes with extra (potentially)
frequently-accessed information and compacting the internal representaion of
the arrow graphs.  perhaps not all of them will be useful before the system
first implements itself in the arrow language, though.

i guess that i could leave the coding to you guys if you're willing.  it
would orthogonalize my aspect of the development quite a bit, since i
wouldn't have to worry about code.  i guess that i could work on my
explanations and help dem with his.

what i can give you is the language definition, and allow you to optimize
the representation of it, probably using the methods that Alexis Read
referred me to, but which i haven't been able to study due to my crippled
internet account.  the basic features that i think are necessary are an
orthogonally-persistent database of objects (arrow-groups), a system for
maintaining intra- and inter-object references, and a means for creating
virtual arrows.  there would probably need to be a heap for the machine
model's internal state in processing arrows.  it would be helpful to have
the system's interface be independent of hardware pointers for the initial
implementation, so that objects' internal representation could be optimized
for specific kinds of operations.

i know that that's a tall order, and i'm willing to compromise in several
areas.  one problem is that i'm not sure how large the object database might
be, although an upper limit of several megabytes seems reasonable for the
prototype, since it will only implement the conceptual framework of the
reasoning system and a simple hardware model in order to implement the
second version via its object system.