[parenscript-devel] Implicit returns

Daniel Gackle danielgackle at gmail.com
Sat Oct 10 16:25:00 UTC 2009


It sounds like other people want this too. Perhaps its time has come!

Failing to add return is a bug that bites us often, and sometimes takes a
while to track down, since the problem can show up in a different part of
the program as "foo is undefined" (where foo was supposed to be the return
value of some function).

We have many thousands of lines of generated JS with lots of returns in it,
which makes for a good regression test for whether a major change like this
has worked or not. The JS shouldn't change much, if at all. If other people
would also do before-and-after diffs on their codebases, that would be a
good way to verify whether implicit return is actually working.

< Though maybe there should be a policy for these incompatible changes >

Yes, there probably should. Personally I'd be fine with a special variable
to turn something like this on or off. A compromise might be to support both
modes for a couple of major releases and then phase out the old way. I'm
just thinking out loud here.



On Sat, Oct 10, 2009 at 5:39 AM, John Fremlin <not at just.any.name> wrote:

> Daniel Gackle <danielgackle at gmail.com> writes:
> [...]
> > Vladimir, have you ever thought of or tried to get RETURN out of PS? What
> are
> > the main challenges?
>
> The lack of implicit return is something that always trips me up writing
> parenscript. I think it would be a good idea. (Though maybe there should
> be a policy for these incompatible changes :-)
>
> It is a bit of effort to implement completely (i.e. marking the last
> form in a defun or lambda to be a returning form, and transforming it to
> use return if it doesn't already), because you would have to figure out
> how to push a return through each special form (e.g. if).
>
> But it sounds feasible . . .
>
> Related to the impedance mismatch between Lisp's view of expressions and
> statements as the same thing and JavaScript's balkanisation of the
> concepts.
>
> [...]
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/parenscript-devel/attachments/20091010/c4d5d6c4/attachment.html>


More information about the parenscript-devel mailing list