to brian

[RE01 Rice Brian T. EM2]

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

Actually, I'd like this thread to stay in TUNES for a little longer for
reasons concerning the machine-model that I'm considering.  I explain
below, although if you still find it compelling, then let me know, so
that I can subscribe.

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

Well, I think you misunderstand my intention with this initial system.
The initial machine model will not be related to a sequential Von
Neumann machine with I/O, registers, instructions, etc.  I intend,
instead, to have the machine model be a system of objects itself,
without numeric algorithms, etc.(this is the specification that I am
currently working on).  The idea I have is to build those constructs for
the Von Neumann machine within the system until, 'behold!' - the system
has the structure to 'port itself' to the new machine model.  I will
have to manually provide the mechanisms to allow this.  Eventually, of
course, the machine model would be the hardware itself, but this is too
far down the road from now.

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

Eureka!  Thank you!  I just made a mental connection.  I now see the
importance of the metaphor between the object/context model and the
partial-evaluation/currying model of function(functor?) application.
I'll chew on that for a while, and get back to it.  I'm amazed that I
didn't see the importance of that viewpoint before.

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

Hmm.  In light of that reasoning, I'll have to re-think that.  I think
that the necessary information that I'm looking for has to do with the
semantic definition implied by the machine's actions, not the object
system (darn! now I'm confusing myself!).  The point is that I don't
trust Ansi/Posix C farther than I can shift bits by taking a square root
(previous expression not intended to make sense), especially if
garbage-collection and orthogonal persistence is going to be
implemented.

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

We agree on having an object system 'mature' into a reflective system,
apparently.  I think that I'm less interested (or not interested at all)
in achieving that with C.

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

Yes, although I consider the proof system an emergent property of the
object system that I wish to build, and that the development will be
geared toward achieving those capabilities.