terminology, bootstrapping

[Tril]

On Tue, 27 Oct 1998, RE01 Rice Brian T. EM2 wrote:
 
> >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.

Ok, then I was misled by the term 'machine model'.  Your machine model is
my 'object system.'  My 'machine model' is your von neumann machine.  I
don't think of the object system as a state machine so that's why I avoid
the term 'machine' when talking about objects.

...I guess since we're talking about the object system this thread really
does not belong in tunes-lll.

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

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

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. 

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

David Manifold <dem@tunes.org>