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 <[email protected]> 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 <[email protected]>: > > 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 > > [email protected] > > http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel > > > > > > _______________________________________________ > parenscript-devel mailing list > [email protected] > http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel >
_______________________________________________ parenscript-devel mailing list [email protected] http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
