to brian

[RE01 Rice Brian T. EM2]

>>> Keep in mind that
>>> my objects are not computational objects in the conventional sense, but
>>> mathematical (logical?) objects within a temporal context (an inadequate
>>> description, I know, but perhaps you will get the gist of it).
>>No, I don't :)  What do you mean "temporal"?
>I would imagine that he means that some mathematical evaluations are not
>possible (or some expressions are not present) at certain times.  "Time"
>is, of course, a series of computational states, with the states
>distinguishable by the computations possible uniquely to each state.
Yes.  This series of states and the computational spaces it generates
are the focus of interest for the 'tracing/debugging' process
>This is one core idea of Evolving Algebras.  Another one is nesting: a
>single state is represented by a single expression, BUT that expression
>might not be simple, in the sense that it might itself have multiple
>states.  If you're willing/able to accept/understand the state expression,
>you don't need to prove/compile the substates.
Right.  That hadn't occurred to me recently when I was working on the
specification for the machine model, but now that you mention that
point, I'll be sure to consider that.
>>> We
>>> should develop a VM which will represent in itself with an (eventually
>>> appropriate) structure of objects (remember that I mean to have each
>>> structure an individual object as well).  
>>There are some grammar problems with this sentence, which makes it even
>>harder to decipher than it would have been with good grammar.  fix?
>He's saying that the virtual machine will be able to be represented via
>its own machine language.  Like metacompiling a Forth.
I enjoy a good metaphor.  Here's a restatement:
The machine model's language space will contain the machine model.
Otherwise, how would it's services(?) be invoked by an automaton of
reason?  Extending this model and coincidentally extending the model's
representation will be a key learning experience for us, I believe.
>I don't like the concept implied by Virtual Machine.  I prefer thinking of
>something else -- perhaps a Machine Model.  Virtual Machine implies that
>the user's machine is trying to be something it's not.  Machine Model
>implies only that the programmer is assuming that the user's machine can
>do certain things.  This seems more Tunesish, if you will.
Yes.  I like that term, too.  It coincides with my model theory
integration approach to reflection.  Henceforth, it shall be the
'machine model'. :)

More in an hour or so...