to brian

[RE01 Rice Brian T. EM2]

>> 	Indeed, my project will resemble yours (David's) in some ways.
>Allright, we've decided to do separate projects. That's what I wanted to
>hear, one way or the other.  You're doing your own because you're sort of
>isolated, OK.  Why don't we work on our own separate projects, and help
>each other on them.  If we're both right, like I hope we are, we'll be
>able to combine our systems as soon as one of them reaches a point
>expressive enough to reason about the other.

Indeed, isolation is my primary constraint (as it has been for a while).

>Let's say the TUNES project is an idea, a goal to strive for.  We (you, I,
>and Fare) are working together on our TUNES ideal from different
>directions.  We should try to create a common terminology, to describe our
>common ideal.  I'm not sure how we can create the terminology now.  Maybe
>we need to learn more about the system, through our implementations,
>first.  Or we can work on it through the discussion list.

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.

>Let's compare our ideas:
>> However, I already have plans to turn it into a proto-Tunes system, with
>> horrible efficiency at first, which will allow us to have a persistent
>> system to reason about in terms of its semantical problems as well as
>> its efficiency problems.  For instance, I'm interested to know what kind
>> and how large the minimal object system will be which can reason about
>> itself (on the VM) in a computationally-complete way.  
>Do you want to reason about semantic and efficiency problems in e-mail,
>talking about the system, or do you want to do that reasoning within the
>system itself?  Please clarify.

I would like both for us to reason about the semantic and efficiency
problems in the mail, and for the system to 'reason' about mathematical
domains.  I will return the latter's results to those who find that
interesting.
>
>> 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 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.
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.

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