[parenscript-devel] What's up with let

Vladimir Sedach vsedach at gmail.com
Mon Aug 18 18:56:47 UTC 2008


> 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).

That was my intention when adding specials to PS. I strongly suspect
there are situations where the semantics differ, but it's good enough
for most common cases without being unduly complex.

Overall, with specials and let vs let* being examples, I'd like
Parenscript code to follow the usual-case Common Lisp semantics to
enable sharing code between the two. This would make the scenario that
Daniel is describing where you'd want the same code to run on the
server and browser a lot less painful. The caveat to this is that the
goal of translation simplicity/generated JS readability/debugability
trumps the former consideration when it comes time to make trade-offs
in how closely CL features are implemented in the generated JS. It all
comes down to making a reasonable compromise, where reasonable is
defined as "is this good/fast enough for the web apps I'm working on
right now?"

The other pitfall is that any differences in semantics between the two
will inevitably cause hard-to-find bugs when the code depends on the
more obscure behavior. That is something I am personally willing to
live with right now, but it's obviously not the right thing.

> 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).

I agree and I'd like to see your design.

Thanks,
Vladimir

> 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
> _______________________________________________
> parenscript-devel mailing list
> parenscript-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
>



More information about the parenscript-devel mailing list