Daniel Gackle wrote:
What you describe would be a good compromise, and I'm fine with using let* instead of let. However, let* doesn't work as you describe in the current darcs version of PS:
(ps (defun blah () (let* ((x 3)) (return x))))
=> [snip...]
You must have previously declared X to be special, as with ps:defvar. Without such a declaration, I get:
function blah() { var x = 3; return x; };
(check your ps::*ps-special-variables*)
As for the handling of specials, what can I say? I didn't add the code that does this, but it appears that the goal was to preserve semantics. It actually seems to do so most of the time (even in the case above, where one might incorrectly assume that the return statement would short-circuit the finally clause).
I'm not certain that the current implementation is quite right though. I picture PS as a compiler, and a compiler shouldn't keep persistent global state. What happens when I want to compile two independent JS files in the same lisp image? Clearly the specials declared in one should not necessarily carry over to the other, as they do currently.
The next time I dive in to make major changes to Parenscript, I plan to find a way to address this coherently, such as by encapsulating the compile state into an object or closure (patches accepted in the meantime, of course). There are valid reasons to want your compile state to be persistent (building JS code on demand to send to the browser during an AJAX session comes to mind).
At any rate, you should be able to avoid the funky try/finally code by either not declaring X special, or (if you otherwise want X to be special), writing:
(ps (defun blah () (var x 3) (return x)))
which, semantically, is the closest to what you really want anyway.
Cheers,
-- Travis