Ok, I pushed a patch deprecating DEFMACRO/PS. If this causes anyone any trouble, let me know.<br><br>Daniel<br><br><div class="gmail_quote">On Mon, Dec 28, 2009 at 5:27 PM, Vladimir Sedach <span dir="ltr"><<a href="mailto:vsedach@gmail.com">vsedach@gmail.com</a>></span> wrote:<br>

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