"layered" language approach (was: Re: Constructors (was: RE: About KCP and automatic initialize))

Brian T Rice water at tunes.org
Fri Sep 19 05:06:14 UTC 2003


On Fri, 19 Sep 2003, Ian Piumarta wrote:
> Brian:
> > Stef:
> > > What I would like to know is much more at a meta level. For example
> > > what are the problem that we can encounter with a macro systems?
>
> I think this is a very interesting question -- not just from an IDE point
> of view, but from a compilation point of view.
>
> An image-based language like Squeak would have all the relevant
> information available when a method is accepted.  So (in a Slatey kind of
> world) when it sees '`foo:' it already knows everything about the method
> behind the "macro selector" #foo:.

(Omitted musings that amount to "What meaning do macros have outside of
the Cult of the Dead?"
(see http://minnow.cc.gatech.edu/squeak/CultOfDead))

> Anyone any bright ideas?

Sure. To take an existing example, the Refactoring Browser uses similar
techniques, and exists in a living world. Perhaps the difference with this
is that RB rewrites are not expressed in the language itself, or is too
much of a separate tool rather than an integrated feature of the existing
system. You can interpret what I'm doing as an extension of this basic
migration from tool to language feature.

At the same time, building up a good set of use-cases for this kind of
generalized facility has not really been done, and will have to be
discovered as I begin to work on tools for Slate. Or perhaps the
difference will lie in the subtle amount of less work that I'll have to do
at each step of the way.

An example is that I can actually implement comments as a macro annotating
the surrounding syntax node. This is a meta-syntactic thing that has
meaning in a living system. The real corner cases involve single macros
which are called in defining a whole framework. In this more complex case,
you merely need to manifestly express the definition of that framework as
an object, and have the link between the definition and framework be
manifest and respected.

> (How does Clean/Haskell deal with this?  [I suppose I should just go look
> it up. ;])

They don't: standard Clean and Haskell's sugarings are generally
statically defined with the language, and of course they are part of the
"Cult of the Dead", building their heaps from declarations in files.

-- 
Brian T. Rice
LOGOS Research and Development
http://tunes.org/~water/



More information about the Squeak-dev mailing list