defining reflection; Classification; OO.

[David Manifold]

On Thu, 29 Oct 1998, Thomas M. Farrelly wrote:

> Tril wrote:
> > But what about a langauge that is written in itself?  Does this constitute
> > a primitive form of reflection, or should it not be called reflection at
> > all?
> 
> Good question.
>
> > What about a language that can modify itself (i.e. is its own macro
> > language) but perhaps cannot express a compiler for itself?
> > 
> What do you mean by macro language here?

Forget about the macro language, that is misleading.  Here's what I meant:

What if I have a Forth interpreter, so I can modify (redefine) Forth
primitives (within the interpreter), but the Forth interpreter was
written in C. It's reflective, but it still requires some external entity
(the compiled C code). 

Perhaps we should coin a term 'internal reflection' for this situation.
I also lean toward 'dynamic reflection' for the ability to modify the
language while it is running.  Then we could describe TUNES as having both
types, and categorize existing languages in one or the other.

A language with dynamic reflection but without internal reflection can
override primitives by replacing them with code written in the language.
It cannot access the code for the language it is implemented in.
(example: the Forth interpreter written in C above)

A language with internal reflection but without dynamic reflection can
modify the language itself but not while it is running.  It cannot
redefine primitives while the language is running.  (example: gcc)

A language like the Forth interpreter above but including a C compiler
written in Forth and access to the C source for the Forth interpreter 
could achieve emulated internal reflection.  That is, it would be able to
redefine primitives by modifying the C code for the Forth interpreter and
executing the C compiler on it.  It would not be able to treat redefined
primitives as first class unless there were hooks in the OS to replace the
currently running binary...

An OS could be hacked up to achieve insecure, but true dynamic internal
reflection by allowing the program to overwrite itself.  This may already
be possible in some OSes that allow self-modifying code.  Ok, so you could
also just exec the new code.  But you'd have to do so in some way that
preserved the state of the running language.  

In TUNES we'd want a proof of the safety of the changes before changing
the implementation, but with a proof allow the operation.

The terms 'internal reflection' and 'dynamic reflection' are what I am
proposing here.  Please tell me what you think.
 
> > Pattern matching.  It's part of typechecking: figuring out what type
> > something is.  A type is a classification.  "Finding orthogonal
> > abstractions" is what the programmer does when creating a new type.
> >
> Yes, and AI is automation of this process.

Typechecking is easy.  Making the typesystem is hard.
Similarly, verifying proofs is easy.  Coming up with proofs is hard..

> [A fully OO system requires reflection]

Okay, I'll buy that.

> The next
> consistent abstraction level is a homogenous system where everything has
> some common properties. What properties? OO is an attempt to resolve
> these problems, I guess. Currently they are not solved. Currently there
> is no OO.

I have no answer to this, except that TUNES allows you to define objects
as sets of properties, and then define what the properties are and what
they mean (in terms of other properties..).

David Manifold <dem@tunes.org>
This message is placed in the public domain.