Hi Ian,

> > Yes ... but I wouldn't consider this to be the same 
> > language anymore.
> 
> Ahh, then we're not talking about the same kind of "level".

Yes, I can see that ;-) My interest was in a kernel language that (on one
level) allows people to write code which is "known to work in the future"
and on another one allows "room for experimentation and improvement".

> > The current "access control" happens by people proving they 
> > are capable of dealing with things like the plugin architecture,
> > know how to write slang, can deal with C compilers etc - all of
> > which I find extremely useful fences.
> 
> Aha.

Indeed ;-)

> Are these fences any more (or less) useful than the "eToy" vs.
> "Smalltalk" fence?

They have pretty much the same goals and are conceptually even almost the
same.

> What do I have to do in eToys to prove that I'm
> "qualified" to drive a browser?

You do have to know how the browser works, what classes are, how Smalltalk
works (including language and library). That's an awful lot for an eToy
user. It's about the same level of fence which we have between Smalltalk and
the VM. However, there is something in eToys which defines another stable
point and that's when you click on the little button which toggles between
tiles and Smalltalk code. This gives you "some of the smell" and allows you
to experiment with a few things that are hard to do otherwise.

Incidentally, I would _love_ it if we had that kind of exposure to the
VM-level too. Essentially something where you can "start to drive" the VM
without having to learn everything at once. Get a smell of the "real bits
flying around" ;-)

> Or the "initializer implies instantiator" vs. "write your own class
> method" fence?  What do I have to do to prove that I no longer need
> X>>+initMe: to instantiate X class>>initMe: automatically, 
> and that I'm "qualified" to push the "class" button in the browser?

Well, for these kinds of fences most of the proofs actually happen by you
successfully doing something. IOW, there is no other proof for you being
able to write a plugin then you doing it. There is no other proof for you
being able to deal with Smalltalk then you doing it. There is no other proof
for you being able to write a meta method then you doing it.

> Or the "primitive and bytecode" abstraction vs. "how it really works
> shunting words around flat memory" fence?  What do I need to 
> do to prove that I'm ready to push the "meta" button in the browser,
> see how dispatch works (and be able to change the one the system
> provides by default, locally to *specific* objects, method, selectors,
> zones, whatever... if that's precisely what I need)?

Then you do it. (didn't I say that somewhere? ;)

> The "brick" wall has another effect: it creates real 
> discontinuities in the implementation "instance" space. 
> I cannot have my personal dispatch semantics running
> in the same image as your application with its own
> personal dispatch semantics.  One or the other has to be 
> incompatible with my VM.  Tear down the wall! 
> Power to the people.  (And other tired cliches.)

We really _are_ in violent agreement ;-) I would like nothing better than to
have a variety of these "stable points" instead of a few brick walls. Alas!
I have yet to come across one that supports it all the way down...

Cheers,
  - Andreas