New Project Coordinator Introduction

[David Jeske]

On Fri, Jan 01, 1999 at 04:34:39AM +0300, RE01 Rice Brian T. EM2 wrote:
> 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.  

Do you have an implementation of a transformation engine for your
arrow system. (or whatever you would call it?) Something which can be
used to experiment with and understand what it is you are trying to
achieve and how it might actually do useful work?

I have tried to read your arrow-system posts, but so far I've not
understood what it actually 'does'. (i.e. it's strength's, it's
weaknesses, where it gets it's power from).

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

I read the words above, and they carry no weight. Your statements
above are tantamount to me saying "tunes is great, it can solve all
computing problems, and it will render all other software
obsolete". Tunes has no example implementation so there is no way for
anyone to prove my statements to be true or false. Likewise for your
arrow language. Until you provide either (a) a specification complete
enough for someone else to understand the arrow-language, or (b) an
implementation which can demonstrate your claims, it makes little
sense to say the things you say above.

Consider the scientific method. Everything you say, so far, is only
hypothesis, until you can prove sufficiently to the rest of the world
that it is true. Show me a C-translation implementation in the
arrow-language, and give me an example of how it handles a sample C
program. Show me examples of HLL, and LLL tasks, how they are handled
in the arrow-language, and give me an implementation so I can see it
for my own eyes. When you have done this, then your words will have
transitioned from a hypothesis into results.

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

Lets take a step back. We know that a turing machine is capable of
doing any computing task. So if your arrow-system is turing complete,
I can assume that your arrow-system can perform any task. However,
that's not interesting to me. Give me an MS-DOS machine with an
assembler, and I can complete any computing task. The idea of Tunes is
to create a computing system which achieves certain efficiency goals
with respect to using and creating software. 

What are the goals of the arrow-system? What things are you trying to
make it do well? What things do you see as un-important?

-- 
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@chat.net