Hi Ian,

> > Pretty much the only thing one needs to make sure is
> > that every program in the kernel language is also a
> > valid program (with the same semantics!) on the level
> > above.
> 
> Well, not always.
> 
> One thing a decent kernel is capable of is modifying the
> apparent semantics (to transition from "implementation" to 
> "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. 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. Even if it looks the same.

> Assuming, of course, you don't want to ever give the
> "application layer" the possibility of digging into its own
> implementation and changing its semantics/pragmatics under 
> its own feet. (Imagine slang and Smalltalk semantics being
> mixed together when accepting Squeak methods: you'd be
> exposing people to a very effective "segmentation
> fault generating facility". ;)

Absolutely. Nevertheless, a valid slang program is also a valid Smalltalk
program with the same semantics. E.g., running InterpreterSimulator does not
mean that suddenly all messages are early bound or that sending #+ will
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 ;-)

> Th "macro selector issue" is an artefact of the current implementation
> stragegy. 

This was used as an example to point out that some "language changes" may
not even be perceived as such.

> There should not be any macro selectors.  The kernel level
> should provide completely general semantics in which they 
> (and arbitrarily many others, and lots of other stuff like
> binding, tagged types, etc.) can be expressed -- in a way
> that use as "natural" a syntax as possible.

This somewhat depends on what you're after and what your intended target
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.
Otherwise you'll end up with all sorts of trouble.

> (Certainly something much more natural than hacking in the guts of the
> Compiler.)  Ideally, I'd say they should look just like regular method
> definitions -- but method definitions that have semantic 
> actions that are applied during compilation, and whose "effect"
> is expressed declaratively, as "Smalltalk patterns" (interpreted
> either in "kernel" or "application" "mode"), and certainly not
> as manipulations on parse tree nodes.

This, again, would be an entirely different language/meta system. I don't
mind this (in fact I'd find it hugely useful) but exposure to these features
needs to _very_ strictly controlled. 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.

> Oops, I'm supposed to be shutting up.  (Sorry about that -- 
> but you hit a "soapbox nerve" there. ;)

And I'm aware of this ;)

Cheers,
  - Andreas