Question

I’m writing a Lisp in Haskell (code at GitHub) as a way of learning more about both languages.

The newest feature that I’m adding is macros. Not hygienic macros or anything fancy – just plain vanilla code transformations. My initial implementation had a separate macro environment, distinct from the environment that all other values live in. Between the read and eval functions I interspersed another function, macroExpand, which walked the code tree and performed the appropriate transformations whenever it found a keyword in the macro environment, before the final form was passed on to eval to be evaluated. A nice advantage of this was that macros had the same internal representation as other functions, which reduced some code duplication.

Having two environments seemed clunky though, and it annoyed me that if I wanted to load a file, eval had to have access to the macro environment in case the file contained macro definitions. So I decided to introduce a macro type, store macros in the same environment as functions and variables, and incorporate the macro expansion phase into eval. I was at first at a bit of a loss for how to do it, until I figured that I could just write this code:

eval env (List (function : args)) = do
    func <- eval env function
    case func of 
        (Macro {}) -> apply func args >>= eval env
        _          -> mapM (eval env) args >>= apply func

It works as follows:

1. If you are passed a list containing an initial expression and a bunch of other expressions…
2. Evaluate the first expression
3. If it’s a macro, then apply it to the arguments, and evaluate the result
4. If it’s not a macro, then evaluate the arguments and apply the function to the result

It’s as though macros are exactly the same as functions, except the order of eval/apply is switched.

Is this an accurate description of macros? Am I missing something important by implementing macros in this way? If the answers are “yes” and “no”, then why have I never seen macros explained this way before?

Answer 1

The answers are “no” and “yes”.

It looks like you’ve started with a good model of macros, where the macro level and the runtime level in in separate worlds. In fact, this is one of the main points behind Racket‘s macro system. You can read some brief text about it in the Racket guide, or see the original paper that describes this feature and why it’s a good idea to do that. Note that Racket’s macro system is a very sophisticated one, and it’s hygienic — but phase separation is a good idea regardless of hygiene. To summarize the main advantage, it makes it possible to always expand code in a reliable way, so you get benefits like separate compilation, and you don’t depend on code loading order and such problems.

Then, you moved into a single environment, which loses that. In most of the Lisp world (eg, in CL and in Elisp), this is exactly how things are done — and obviously, you run into the problems that are described above. (“Obvious” since phase separation was designed to avoid these, you just happened to get your discoveries in the opposite order from how they happened historically.) In any case, to address some of these problems, there is the eval-when special form, which can specify that some code is evaluated at run-time or at macro-expansion-time. In Elisp you get that with eval-when-compile, but in CL you get much more hair, with a few other “*-time”s. (CL also has read-time, and having that share the same environment as everything else is triple the fun.) Even if it seems like a good idea, you should read around around and see how some lispers lose hair because of this mess.

And in the last step of your description you step even further back in time and discover something that is known as FEXPRs. I won’t even put any pointers for that, you can find a ton of texts about it, why some people think that it’s a really bad idea, why some other people think that it’s a really good idea. Practically speaking, those two “some”s are “most” and “few” respectively — though the few remaining FEXPR strongholds can be vocal. To translate all of this: it’s explosive stuff… Asking questions about it is a good way to get long flamewars. (As a recent example of a serious discussion you can see the initial discussion period for the R7RS, where FEXPRs came up and lead to exactly these kinds of flames.) No matter which side you choose to sit at, one thing is obvious: a language with FEXPRs is extremely different than a language without them. [Coincidentally, working on an implementation in Haskell might affect your view, since you have a place to go to for a sane static world for code, so the temptation in “cute” super-dynamic languages is probably bigger…]

One last note: since you’re doing something similar, you should look into a similar project of implementing a Scheme in Haskell — IIUC, it even has hygienic macros.