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@just.any.name> wrote:
Daniel Gackle <danielgackle@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.

[...]