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
