Constructors (was: RE: About KCP and automatic initialize)

Ian Piumarta ian.piumarta at inria.fr
Wed Sep 17 16:00:41 UTC 2003


Hey Andreas,

On Wed, 17 Sep 2003, Andreas Raab wrote:

> > > that every program in the kernel language is also a
> > > valid program (with the same semantics!) on the level
> > > above.
> > "application" semantics) and then (the final step) removing
> > all traces of its original semantics from the system --
> > leaving you with the impression that you never had any
> > "kernel" magic in the first place.
>
> 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".

> If an expression I write in the kernel language is either invalid or has
> a different semantics on a higher level layer then they are really two
> different languages.

That expression wouldn't even be being expressed in the kernel language
any more.  So again, I think your "level" and mine are not quite the same
thing.

> Absolutely. Nevertheless, a valid slang program is also a valid Smalltalk
> program with the same semantics.

Not really.  I cannot replace SysDict>>primSnapshot with the current Slang
definition to which it's bound, accept the method, and then expect it to
work.  (If you were to recast Slang in terms of my definition of "kernel
level" then this is precisely the kind of thing you _have_ to be able to
do.)

> suddenly truncate Integers to 32bits or somesuch. In this sense, Slang (with
> all of its restrictions) is a kernel language for Smalltalk, just a very
> poor one ;-)

And independent.  It's not really a layer -- it's a parallel universe,
with many similarities (and some cases where meanings are equivalent)
but which contains semantics (and above all pragmatics) that cannot be
reified at runtime within Smalltalk itself.  You have to compile it
offline and restart the VM to affect the change.  When you run InterpSim
you aren't executing your image, but a simulation of an image inside your
image.  Your layers are independent -- there's no continuous transition
possible from one to the other.

Otherwise we'd be able to fire up InterpSim on the in-memory image of the
currently-running image.

(See: you and me, we have different "layers". ;)

> audience is. If you are talking about a kernel which is never touched by any
> "end-users" but only by system designers, then I guess you're right.

It's just part of the natural progression from (1) eToys to (2)
tweakyscript [whatever] to (3) instance-only-level Squeak to (4)
instance+class-level "real" Squeak to (5) instance+class+implementation
meta-level Squeak.

We have (1)-(4), but there's currently a phase transition to connect with
(5).  That's what I don't like.  Dicontinuity in something that should be
continuous.  (I came to these conclusions a long time ago, by staring with
(6) [or even (7)] and then working backwards towards (1) -- but now I lay
it out like this, it makes even more sense when approached from the (1)
end.)

> Otherwise you'll end up with all sorts of trouble.

Absolutely.  we need to find stable points in any system so as not to
scare people away with too much generality (it _terrifies_ people).
You've already done this with eToys, a stable point before Smalltalk.
You're currently trying to do this with new/init, a stable point before
seeing the Metaclass layer...

Wouldn't it be more honest if we could define stable points (1) through
(4) (as we have now) and then, for the few who have the courage, let them
proceed unhindered (by offline compilation nonsense) directly to stable
point (5)?  (And beyond...)

If you can't do something in eToys   you hack their methods.

  "     "        "           methods              class/compiler/whatever

  "     "        "       class/compiler/...   |    implementation
                                              :
                                              :
         traditional brick wall --------------+

> This, again, would be an entirely different language/meta system.

Yup.  Did I mention "we have different layers"?  ;)

> I don't mind this (in fact I'd find it hugely useful)

If you want to build a language that can really evolve experimentally,
it's essential.

> but exposure to these features needs to _very_ strictly controlled.

I think we're in violent agreement.  (FWIW, it's just creme brulees.)

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

Are these fences any more (or less) useful than the "eToy" vs.
"Smalltalk" fence?  What do I have to do in eToys to prove that I'm
"qualified" to drive a browser?

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?

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)?

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

> > but you hit a "soapbox nerve" there. ;)
> And I'm aware of this ;)

- Est-ce que ca vous gratouille, ou est-ce que ca vous chatouille ?
- Non, ca me *demange*.  ;) ;) ;)

Ian



More information about the Squeak-dev mailing list