Croquet alpha release(s?)

Brian T Rice water at tunes.org
Sat Dec 7 19:28:02 UTC 2002


On Sat, 7 Dec 2002, Rob Withers wrote:

> What would a macro system look like in squeak?  could you effectively browse
> implementors and senders of the macro symbols?

Slate prepends ` to a selector name to have be applied at compile-time.
That is, it's arguments would be the object trees representing the parsed
form of the expressions. What the macro expression returns needs to also
be a SyntaxNode (our root kind of parse node), since it is substituded
back into the surrounding expression. However, `quote and `unquote easily
make this possible for arbitrary expressions.

When "macro-sends" are distinguished this way, it makes it very simple to
find the definition of it. In fact, the method used for that message-send
is statically-knowable for static source. One browser idea we have to make
macros usable is a graphical stepper through macro-expansion, with a bit
of highlighting. But that doesn't apply as easily to dynamically-generated
whole systems and such; unless the browsing context were built
dynamically. I guess that might apply for debugging; I'll have to think
about that.

We also haven't adopted any macro uses into our code yet, as a general
rule until we have a working bootstrapped system.

> note that in this case i don't have a technical issue with the compiler hack
> because they are turned into msg sends.  Assignment and return are syntax
> which I would _love_ to see become msg sends.  this could be done with
> macros, couldn't it?  if the lookup fails for those selectors, we could
> fallback to the vm bytecode handler.   assignment could expand to
> 'thisContext assign: value to: variableBindingOrSymbol' and return could
> expand to 'thisContext return: value'.  then jit it.
>
> rob

Slate does use ^ as a message send to the context, but it's not a macro,
probably because we use ` to syntactically-distinguish them, for the
benefits mentioned above. There is a bit of a precedence issue with this:
returning a keyword- or binary-send result requires. Even #return:
requires some precedence-specifying for later keyword-sends.

As for assignment, we don't expose that, although assign:to: sounds like a
pretty decent idiom. Our current practice is to perform everything through
accessors; our multi-dispatch semantics somewhat force us to do that; our
plan is to provide hooks for defining custom methods for access and update
through a MOP. Currently, we use #atSlotNamed:(put:) which is a bit hefty.

And we're very unlikely to add [,]. Probably we'd do the same with a macro
that takes an array with the arguments, or a macro with some optional
keywords. We also might try empty keywords, but that's not easy to deal
with for the reader.

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




More information about the Squeak-dev mailing list