I need to do a bit of Parenscript hacking for my project and thought I'd upgrade to the latest source first. I had to roll back to the released version, though, because of problems with how code is being generated for let.
First, the semantics of let have changed to be more Lisp-like. Is that correct? This causes some practical problems. In much of our app, performance is critical and we can't afford to have temporary variable reassignment, try/finally, and delete magic going on under the hood. What we need is plain-old, naked Javascript variable assignment - the simplest generated code possible. As of 20071104, that's exactly what PS generated for let. Now, it generates code that's considerably more complex, which we mostly can't use.
Second, there's the philosophical question (debated on this list several times) about how Lispy Parenscript should try to be. There are good arguments either way, but it seems to me important to remember that Parenscript is not a CL-to-JS compiler, it's JS (plus macros) embedded in CL. The bias so far, which I agree with, has been "when in doubt, adhere closely to JS semantics", because we need the generated JS to be fast, readable, and easy to debug. That's a big deal if you spend a lot of time working with the JS in Firebug (which we do). It seems to me that a CL-to-JS compiler is impractical unless two conditions are fulfilled: the standard JS interpreters are performant enough to handle it, and we no longer have to work manually with the generated code.
My questions are: (1) Does anyone need Lispy let, or can we just take it out and revert to the simpler let? (2) If it really is needed, can we come up with an easy way to offer the user their choice of assignment semantics (perhaps a special variable)?
In the meantime, I'll switch back to 20071104.
Daniel