Ok, I pushed a patch deprecating DEFMACRO/PS. If this causes anyone any trouble, let me know.
Daniel
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@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@common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
>
>
_______________________________________________
parenscript-devel mailing list
parenscript-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel