[parenscript-devel] DEFMACRO/PS considered harmful

[Daniel Gackle]

Ok, I pushed a patch deprecating DEFMACRO/PS. If this causes anyone any
trouble, let me know.

Daniel

On Mon, Dec 28, 2009 at 5:27 PM, Vladimir Sedach <vsedach at gmail.com> wrote:

> Makes sense to me. As long as IMPORT-MACROS-FROM-LISP is there there's
> nothing really lost.
>
> Vladimir
>
> 2009/12/28 Daniel Gackle <danielgackle at gmail.com>:
> > The following is probably overkill, since it may be that nobody is
> actually
> > using the simple two-line macro that I'm about to propose getting rid of.
> > But the issues here are at least marginally interesting and there may be
> > some value in writing them up.
> >
> > There are two ways to define a macro to work in both Lisp and PS,
> > DEFMACRO/PS and DEFMACRO+PS. The difference between the two is rather
> > obscure. In practice, the main effect is that if you define your macro
> with
> > the former, then PS will generate its code from the *Lisp* macroexpansion
> of
> > the form.
> >
> > Out of dumb habit, my practice until recently was this:
> >
> > 1. Use DEFMACRO/PS, unless
> > 2. A bug occurs because the Lisp macroexpansion makes no sense in JS;
> > 3. Spend time tracking down the bug
> > 4. Switch to DEFMACRO+PS in that case.
> >
> > Then it dawned on me that I had been bitten by this an embarrassing
> number
> > of times. I decided to see what would happen if I replaced all uses of
> > DEFMACRO/PS with DEFMACRO+PS in our code, and inspected a diff of the
> > resulting JS. My two findings were:
> >
> > (1) I discovered several places where, unbeknowst to us, we were ending
> up
> > with unintended JS. For example, if we DEFMACRO/PS'd a macro which
> expanded
> > to a logical operator like AND, then PS would generate code from the Lisp
> > macroexpansion of AND instead of the obvious &&. The resulting JS wasn't
> > necessarily incorrect, but it was clearly the wrong code.
> >
> > (2) There were no cases at all where DEFMACRO+PS didn't do what we
> wanted.
> >
> > Accordingly, I propose that DEFMACRO/PS be eliminated:
> >
> > 1. It adds little if any value.
> > 2. In the rare case that it does add value, you can easily define your
> macro
> > explicitly to do what you want.
> > 3. It's error-prone (including some errors that go without detection).
> > 4. The distinction between it and DEFMACRO+PS confuses everybody who sees
> it
> > for the first time (if not the first ten times).
> > 5. It's a mistake to blur the distinction between the Lisp macro
> environment
> > and the PS one. It's sometimes handy to make a macro to work the same way
> on
> > both sides (DEFMACRO+PS), but that's not the same thing as mixing the
> > underlying two environments.
> > 6. As PS has evolved and we've learned more about how to use it well,
> > DEFMACRO/PS is an anachronism. I think I might have been its original
> > author, in which case I am certain that the thinking behind it was
> confused.
> >
> > In short, off with its head!
> >
> > Daniel
> >
> >
> >
> >
> > _______________________________________________
> > parenscript-devel mailing list
> > parenscript-devel at common-lisp.net
> > http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
> >
> >
>
> _______________________________________________
> parenscript-devel mailing list
> parenscript-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/parenscript-devel/attachments/20100104/699bebb5/attachment.html>