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@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@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:
- Use DEFMACRO/PS, unless
- A bug occurs because the Lisp macroexpansion makes no sense in JS;
- Spend time tracking down the bug
- 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:
- It adds little if any value.
- 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