[parenscript-devel] What's up with let

[Daniel Gackle]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/parenscript-devel/attachments/20080809/7bb477ff/attachment.html>