[parenscript-devel] What's up with let

[Travis Cross]

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