<div class="gmail_quote">On Sat, Oct 10, 2009 at 9:25 AM, Daniel Gackle <span dir="ltr"><<a href="mailto:danielgackle@gmail.com">danielgackle@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
It sounds like other people want this too. Perhaps its time has come!<br></blockquote><div><br>Hear, hear.<br><br>-Red <br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>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).<br>


<br>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.<div class="im">
<br>

<br>< Though maybe there should 
be a policy for these incompatible changes ><br><br></div>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.<div>
<div></div><div class="h5"><br>

<br><br><br><div class="gmail_quote">On Sat, Oct 10, 2009 at 5:39 AM, John Fremlin <span dir="ltr"><<a href="mailto:not@just.any.name" target="_blank">not@just.any.name</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">


Daniel Gackle <<a href="mailto:danielgackle@gmail.com" target="_blank">danielgackle@gmail.com</a>> writes:<br>
[...]<br>
> Vladimir, have you ever thought of or tried to get RETURN out of PS? What are<br>
> the main challenges?<br>
<br>
The lack of implicit return is something that always trips me up writing<br>
parenscript. I think it would be a good idea. (Though maybe there should<br>
be a policy for these incompatible changes :-)<br>
<br>
It is a bit of effort to implement completely (i.e. marking the last<br>
form in a defun or lambda to be a returning form, and transforming it to<br>
use return if it doesn't already), because you would have to figure out<br>
how to push a return through each special form (e.g. if).<br>
<br>
But it sounds feasible . . .<br>
<br>
Related to the impedance mismatch between Lisp's view of expressions and<br>
statements as the same thing and JavaScript's balkanisation of the<br>
concepts.<br>
<br>
[...]<br>
<br>
</blockquote></div><br>
</div></div><br>_______________________________________________<br>
parenscript-devel mailing list<br>
<a href="mailto:parenscript-devel@common-lisp.net">parenscript-devel@common-lisp.net</a><br>
<a href="http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel" target="_blank">http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel</a><br>
<br></blockquote></div><br>