New Project Coordinator Introduction

[RE01 Rice Brian T. EM2]

> > 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?
> 
not in code, no.  that's the prototpye that i've been talking about.  it's
existence is supposed to allow the testing of all of these hypotheses.  it's
in the design of the thing (which is proceeding right now) that i intend to
find answers to my questions.  right now, what i do is run traces of an
abstract C-program in my head and reason about short-term analyses.

> 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.
> 
i agree.  well, here's a preliminary answer...

we could define a C finite-state machine using arrow diagrams.  if you think
that i need to prove that this can be done, then you really have no
imagination.  directed multi-graphs have been used for representing
finite-state machines for over 50 years.  i should simply be able to state
that binary data storage as an atomic metaphor is simple to encapsulate with
arrow-diagrams, and that everything else on the computer (aside from
asynchronous operations) can easily be expressed in terms of this base
machine.  as for asynchronous operations, those will be defined
axiomatically, since they are infinite in state-cardinality.  the basis for
that statement is that such a system cannot be deterministically specified,
just as you can never rely on a hard-drive's precise seek time to a
particular point based on position information or something equivalent.
this is where the NP-complete problems lie, and i don't pretend that they
are simple.
we also would have a definition of our target architecture in hardware, also
a finite-state machine (once again, separating out asynchronous devices from
this statement).
the semantics of the C language would allow us to extract a little
meta-information about the program.  the entire semantics of the language
are quite simple to encompass, since the C language is little more than
macro-assembler.  we basically define it in terms of the implicit rules of C
programming, including consistency between declaration and invocations of
program objects (functions, etc.).  we also, due to being subject to the
Arrow system's infinitary analysis system, include the specified implicit
semantics concerning the behavior of a 32-bit field vice an 'actual'
integer, so that error-handling is not really about an error or an
exception, just a complication in the ability to analyze the program
formally.
i'll elaborate based on your questions...

[HLL vs LLL] in my opinion, the only languages which the Arrow system will
consider high-level are abstract languages: those which express unbounded
integers, for instance, and/or infinite-state machines.  everything else
will be reducible to some variation on the C-theme: the ability to control
the computer absolutely being the goal of such languages, expressing their
inapplicability to Tunes rather succinctly.

[about efficiency]

hmm..  an answer is forthcoming.