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

Ian Piumarta ian.piumarta at inria.fr
Fri Sep 19 04:11:05 UTC 2003


Brian:
> Stef:
> > Yes the scheme macro for example. I would really like to know what is a
> > good macro system for a Smalltalk.
>
> For reference, Slate has been managing to simplify some language aspects
> such as is the case for its macro system:
> Where preceding a selector with ` will result in applying it to its'
> arguments parse objects
>
> > 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:.

In Scheme one loads everything into an empty world, including macro
definitions before their uses.  (Dumping the Scheme state to a file to
make a turnkey application just includes any macro-expanding functions
along with the dump.)

But what if we wanted to add this kind of "intelligent macro" to something
like Objective-C (or a file-based Smalltalk) capable of making *static*
executables out of seperately-compiled program units? Moreover, if we
wanted to make macros transparent to the programmer (eliminating the "`"
and making the compile-time expansion an implicit property of the selector
symbol itself maybe in combination with its receiver/argument types) we'd
need the definition to be avilable for every compilation unit in which the
macro was (implicitly) referenced.

The obvious thing would be to put the macro definitions in the interface
header files (like with cpp macros) but somehow this seems distasteful.
Loading in lots of class implementation files wouldn't work either (since
there would be lots of multiply-defined methods in the final exectuable).
The only other thing I can think of would be to have three kinds of source
file: interfaces, "regular" class implementations, and macro
implementations.  But somehow that doesn't appeal to me much either.

Anyone any bright ideas?

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

Cheers,
Ian



More information about the Squeak-dev mailing list