[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

macros



    Jonathan:
    I'm not saying there shouldn't be a macro facility, or that the
    language shouldn't have a limited amount of syntactic sugar, but
    rather that I practically never see a legitimate use of a macro
    by anyone other than a language designer.

Of course, this begs an answer to the question: "What is a language
designer?"  It would be tempting for each of us to argue that the only
time we use macros is when we're playing the role of language designer;
it's a rather subjective concept.

In fact, for a language designer, macros are a rather constrained
form of syntactic extension -- one might ultimately prefer tools that
allow full context-free parsing.  Since such tools don't currently
exist in the convenient framework of a REPL and it's associated
utilities (which is what's so nice about macros), then one has to
resort to source-to-source transformations (compilation!) if macros
don't fill the bill.

    If people have good counterexamples to this argument, I would
    like to see them.

I almost never use macros, because it's almost always the case that
procedural abstraction will do the job just as well (usually better).
But it seems to me that legitimate uses of macros are always tied
to the desire to delay the evaluation of something.  For example,
one of three macros that we use in the ALFL compiler is the following
very *simple* one:

    (define-syntax (smt ob)
        `(let ((done ()))
           (lambda ()
              (if done done (set done ,ob)) ) ) )

SMT stands for "self-modifying-thunk" and is our way of emulating
graph-reduction without the inefficiency of T's DELAY (this works
because () is not a valid value in ALFL).  Do you think this use is
legitimate?  If so, am I being a language designer?  I suppose I could
have used a procedure like:

    (define (smt delayed-ob)
        (let ((done ()))
          (lambda ()
             (if done done (set done (delayed-ob))) ) ) )

but then I would incur the inefficiency of *two* nullary closures
instead of one.

    -Paul