[bitc-dev] Macro removal rationale

[Jonathan S. Shapiro]

On Thu, 2006-07-20 at 18:17 +0200, Michael Weber wrote:
> * "Jonathan S. Shapiro" <shap at eros-os.org> [2006-07-20T12:04-0400]:
> > In the end, there were three factors:
> > 
> > 1. My conclusion that building a "clean" macro system (one that does not
> > capture the wrong identifiers) is extremely tricky and the result tends
> > to be hard to use.
> 
> This is a little surprising.  The Scheme community spent quite some on
> this, and one would have thought that there is a suitable compromise.

Actually, the experience of the Scheme community is part of what
convinced me *not* to try to do a macro system. The scheme macro system
is probably the most mature and carefully considered example out there.
It is *horribly* complex, and the scheme community isn't done tinkering
with it. It is exceptionally easy to build a scheme macro with
unforeseen consequences, and very simple to build one that botches
lexical environments.

Matters become even more complicated in a typed language, where the
macro system must build well-typed transforms. At the point where the
macro processor runs, the type checker has not, so type information is
not yet available from the compiler. There is (so far as I know) only
*one* example of a macro system for such a language, and it is even more
complex than the Scheme macro system.

I am not opposed to macros. I simply felt that this was a problem that
we shouldn't try to take on while we were working on everything else
too.

> > 3. Mark Miller's observation that macros obscure readability by making
> > it harder to understand what the code in front of you actually does.
> 
> Macros also ensure that, e.g., resources are properly freed, leaving
> no room there for errors.  Examples: WITH-OPEN-FILE and friends.

Macros are not required for this -- and in fact, WITH-OPEN-FILE is a
great example of something that you *don't* want to do in Scheme because
there is no guarantee that the catch handler will ever execute!

shap