to brian

[David Manifold]

NOTE: I set replies to this message to go to TUNES-LLL.

We should move discussion about low-level machines, bootstrapping, and our
particular implementations to the TUNES-LLL list.

On Mon, 26 Oct 1998, RE01 Rice Brian T. EM2 wrote:

> >Let's say the TUNES project is an idea, a goal to strive for.  [...]
> 
> All these ideas are good.  Consider me in, with source code forth-coming
> when ready (and legible).  But first, the specifications of the
> machine-model should be our topic.

I'm not ready to implement a machine model yet, but maybe that's a good
reason to talk about it now.

When I do get to describing the machine abstractly in the reflective
system, I'll do things like: mathematically define the machine as an
algebra (sets with operations on the sets): a set of CPU registers, a set
of memory locations, and a set of I/O addresses, with CPU instructions
operating on the sets.

> >> Everything at first will have to be an explicit object (defined as
> >> elements of main memory) to the VM.  Their fields will not even directly
> >> be attributes, since those will be separate objects themselves.  Other
> >> objects will not exist, at first.  I believe that this kind of rigorous
> >> definition will give us the appropriate framework to start from.  
> >[and from later on in the message]
> >> Eventually, the VM should be able to deal with objects not explicitly
> >> laid out in memory as separate atoms.  
> >I'm not sure what it is you are making "explicit" here.  What do you mean
> >"elements of main memory"?
> 
> I mean to express all objects (as seen by the source C-code) initially
> as data structures in C.  The significance is the 'all' in 'all
> objects'.  Of course, if I can reasonably skip this stage for any
> objects without losing some semantic integrity, then I will (suggestions
> are invited).  For instance, every instance of '(un)countability' must
> be 'factored out' into the machine model, with only the structure of it
> in object-representation.  Naturally, this is the most difficult aspect
> of coding of the machine-model (aside from using the C-language in
> Win32).

I'm using arrays of int[10] for objects :)

Hardware access, invoking functions, and constructing expressions (code or
data) are all expressed as copying objects into a context.  This
simplifies everything to a drag-n-drop operation (no GUI yet, but
conceptually the same).

> >> I want to trace the operations
> >> of the system as it interacts with the user through a dialog interface
> >> and study the results to evaluate our design considerations for the VM.
> >Design considerations?
> >Who is tracing whom?  Are you tracing my use of the system, or your own?
> >Is the user interacting with the dialog interface, or are you tracing the
> >system using a dialog interface (ambiguous grammar)?
> 
> For the most part, I would be the user as a 'profile' is generated.
> Then I suppose to view the profile (like a dialog session transcript)
> and learn from it.  Or I could just enrich the dialog session itself
> with intermediate computations by the system displayed.

I don't understand exactly what you are profiling.  When I think of
profiling, I think of a complete UI and testing how easy it is to use.
How can you design better semantics by watching yourself use the system??
Wouldn't you still have to come up with such better semantics?  Profiling
would imply that some things had OK semantics and others did not.  I
thought you meant the entire method of specifying meaning in the system in
general.  I don't see how that can be improved with any kind of log
analyzing.  (I don't want to discourage you, just explain a little more)

> By design considerations, I mean the semantic definition for the model
> and its representation.  Eventually, this definition should allow
> reflection to be implemented, instead of simulated by the user updating
> the machine-model representation manually when source-code is changed.

There's no reflection in tunes.c yet, it's simulated by interpreting
operations using prewritten C code.  I don't expect full reflection soon;
that would require logic, mathematics, memory management and looping
constructs, to express the equivalent of the C code I have in the object
system.

> >> Even the creation of new contexts
> >> should be done without changing the scheme for representing objects,
> >> until that is we have developed the ideas necessary to include this
> >> within the system's capabilities in a Tunes-friendly way.
> >Everything should use one representation for objects?  I have that, too.
> 
> I know.  I'm just trying to maintain it (though it will be quite a
> cumbersome interface for the purposes of describing the structures I
> intend on using) until I feel satisfied in being able to make parts
> implicit in a way which does not destroy information.

For recursively defined stuff I can't check for infinite loops without a
proof system (which will be a while) so I'm just taking care not to make
them.  Is that sort of what you mean?

David Manifold <dem@pacificrim.net>