On Wed, 17 Sep 2003, Andreas Raab wrote:

> Other systems have found pretty reasonable ways of dealing with it (or at
> least so I think). For example, using a "layered" language approach could be
> helpful. On a low level, there is a "kernel language" and on top of it sit
> all of the added elements (syntactic or semantic sugar). 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.  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". ;)

If you do want that possibility, you can just have a "switch" (imperative
or declarative).  If the kernel and application layers are expressed in
the same syntactic structures then you absolutely need such a switch to
turn off the generality present in the kernel layer for "application"
users.  Here's a trivial (but pertinent) example:  the same expression in
TeX's "kernel" and "application" layers can mean two very different
things, so TeX gives you \makeatletter and \makeatother to reveal
(effectively) and subsequently hide again its "kernel" level, as required.

> > use in another). In Smalltalk, code is a material that the environment
> > executes and exposes for shaping by the user. Code is always defined
> > or modified by the user, though some tools help him do so.
>
> Is that so? I guess it depends on how you look at it. How would you (in this
> light) see inline compilations of, e.g., #to:do: or #ifTrue:ifFalse:
> #ifNil:ifNotNil:? This is not what the user writes even if the system (by
> implementing these messages) makes him think that it would be.

Th "macro selector issue" is an artefact of the current implementation
stragegy.  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.
(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.  (Unless,
by some implementation magic, the former is isomorphic to the latter. ;)

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

Ian