Constructors (was: RE: About KCP and automatic initialize)
Andreas Raab
andreas.raab at gmx.de
Wed Sep 17 15:01:11 UTC 2003
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
More information about the Squeak-dev
mailing list
|