terminology, bootstrapping

[RE01 Rice Brian T. EM2]

>> >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.
>I don't think an implementation of C is necessary to bootstrap, if that's
>what you mean.  What I meant was porting the code from C into the
>framework implemented by the C code.  The framework doesn't have to
>implement C... it should begin to implement various abstract paradigms of
>computing, like functional, parallel, OO, and logic programming.

Yes, we agree fully.  Something that I was trying to get across was that
we may have to re-implement the machine model with another language,
like Self or Smalltalk or Beta, in order to ease the development of
reflection.  Otherwise, it may become nearly impossible with the dirty
semantics of the C-language.  I think that we should wait on this
decision until we really have to, or can concretely foresee the need.

>I don't plan on having a textual representation for tunes at all, not a
>linear syntax, not even a minimal one like LISP.  I'll implement
>everything graphically or using structures that you interact with.  I
>don't know how to explain this better right now. 

Ok.  We could build an interface into the machine model to support
text-dialog type statements to represent the objects, or a graphical
representation of the relationships within a GUI.  We probably shouldn't
include the complexity of these interfaces in the system's description
of the machine model, to keep the development simple, but instead
include some minimal interface description instead.  (This proposal
needs serious revision.)  To elaborate, this interface could be a single
object which virtually passes all objects to an "off-world" site.  This
seems naïve, and would definitely be a candidate for implementation only
in the machine model, not in the object system, at early stages.  In my
idea, everything would be an object.  Properties of objects, messages,
statements, relations, and operators would all be objects, as well as
the shapes (patterns) they describe that the system would benefit from
manipulating.

>> >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.
>I've got to leave room for parallelism, distribution, persistence, as well
>as proofs...and add everything incrementally but simultaneously when
>necessary.

I can see that most of these things will be necessary, but the proof
system seems to apply to those properties as well, for instance in
describing the capabilities of an algorithm for data-flow routing
between network nodes or something of that sort.  Maybe I'm wrong about
that, in that we may quite easily be able to do those things without
proofs for the most part, but I can't say for sure just yet.