Thanks! I've upgraded and removed our return-from-catch hack. A few bits of feedback from the latest round of changes:<br><br>1) The generated code for calling setf functions is much cleaner. Whatever you did, it addressed my concern.<br>
<br>2) Commit c08b0525 (removal of WITH-LAMBDA macro, which I agree was ugly and needed removing) inadvertently broke the PS LOOP macro's accumulation clauses (COLLECT etc.). I've pushed a fix.<br><br>3) We are delighted with how well implicit RETURN is working. Not only did it remove the greatest single impedance mismatch between Lisp and JS, but I've noticed anecdotally that there are fewer occasions on which my code works in Lisp but fails in JS. I was expecting such a huge change to have more glitches, but other than the initial round of bugs we reported, there appear to be none. Thanks for biting the bullet and getting that done.<br>
<br>Daniel<br><br><div class="gmail_quote">On Fri, Dec 25, 2009 at 12:59 AM, Vladimir Sedach <span dir="ltr"><<a href="mailto:vsedach@gmail.com">vsedach@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;">
Done.<br>
<br>
2009/12/3 Daniel Gackle <<a href="mailto:danielgackle@gmail.com">danielgackle@gmail.com</a>>:<br>
<div><div></div><div class="h5">> Just to follow up on this point:<br>
><br>
> < Regarding try/catch, I'm still on the fence. Anyone have try/catch use<br>
> cases where implicit return is not what would be wanted? ><br>
><br>
> It seems pretty clear to me that there should be implicit return inside<br>
> CATCH blocks. After all, there is implicit return inside TRY, and by<br>
> definition, the code was never able to actually execute that return.<br>
> Something ought to take its place. We have three or four usages where we've<br>
> had to hack an explicit return back into our PS, just so that an error<br>
> object makes it out of CATCH.<br>
><br>
> Equally important, it seems to me, is that FINALLY blocks *not* provide<br>
> implicit return. Either a TRY or CATCH has already specified a return value;<br>
> FINALLY is usually for tying up loose ends, not overriding the return value.<br>
> In other words, I think the existing behavior around FINALLY is good.<br>
><br>
> If no one objects, can you go ahead and put implicit return into CATCH so I<br>
> can take out our hack?<br>
><br>
> Daniel<br>
><br>
><br>
><br>
> On Sun, Nov 22, 2009 at 12:27 AM, Vladimir Sedach <<a href="mailto:vsedach@gmail.com">vsedach@gmail.com</a>> wrote:<br>
>><br>
>> I've just pushed a patch that should address all the issues raised so<br>
>> far in this thread. Thank you for the QA Scott!<br>
>><br>
>> Regarding try/catch, I'm still on the fence. Anyone have try/catch use<br>
>> cases where implicit return is not what would be wanted?<br>
>><br>
>> Vladimir<br>
>><br>
>> 2009/11/5 <<a href="mailto:sblist@me.com">sblist@me.com</a>>:<br>
>> > Vladimir and friends,<br>
>> ><br>
>> > In the following example, do you think that both<br>
>> > the try block and the handler blocks should receive<br>
>> > an explicit return?<br>
>> ><br>
>> > I'm not absolutely convinced, but I think that it<br>
>> > probably should.<br>
>> ><br>
>> > PS> (ps (lambda () (try (foo) (:catch (e) e))))<br>
>> > =><br>
>> > "function () {<br>
>> > try {<br>
>> > return foo();<br>
>> > } catch (e) {<br>
>> > e;<br>
>> > };<br>
>> > };"<br>
>> ><br>
>> > - Scott<br>
>> ><br>
>> > On 2009-11-04, at 12:57 PM, Vladimir Sedach wrote:<br>
>> ><br>
>> >> Hello,<br>
>> >><br>
>> >> Many of you have been asking for this for a long time, and based on<br>
>> >> feedback (as well as my own experience) the lack of this feature has<br>
>> >> been the biggest cause of bugs in PS code, so it's with a bit of joy<br>
>> >> that I just pushed out a patch to add implicit returns to PS functions<br>
>> >> (including lambdas and flet/labels) to the repository just now. Please<br>
>> >> try it out and report any bugs you find!<br>
>> >><br>
>> >> Thank you,<br>
>> >> Vladimir<br>
>> >><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>
>> ><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>
>><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>
><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>
><br>
<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>
</div></div></blockquote></div><br>