[parenscript-devel] Implicit return for function bodies
Hello, Many of you have been asking for this for a long time, and based on feedback (as well as my own experience) the lack of this feature has been the biggest cause of bugs in PS code, so it's with a bit of joy that I just pushed out a patch to add implicit returns to PS functions (including lambdas and flet/labels) to the repository just now. Please try it out and report any bugs you find! Thank you, Vladimir
Vladimir and friends, In the following example, do you think that both the try block and the handler blocks should receive an explicit return? I'm not absolutely convinced, but I think that it probably should. PS> (ps (lambda () (try (foo) (:catch (e) e)))) => "function () { try { return foo(); } catch (e) { e; }; };" - Scott On 2009-11-04, at 12:57 PM, Vladimir Sedach wrote:
Hello,
Many of you have been asking for this for a long time, and based on feedback (as well as my own experience) the lack of this feature has been the biggest cause of bugs in PS code, so it's with a bit of joy that I just pushed out a patch to add implicit returns to PS functions (including lambdas and flet/labels) to the repository just now. Please try it out and report any bugs you find!
Thank you, Vladimir
_______________________________________________ parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
I've just pushed a patch that should address all the issues raised so far in this thread. Thank you for the QA Scott! Regarding try/catch, I'm still on the fence. Anyone have try/catch use cases where implicit return is not what would be wanted? Vladimir 2009/11/5 <sblist@me.com>:
Vladimir and friends,
In the following example, do you think that both the try block and the handler blocks should receive an explicit return?
I'm not absolutely convinced, but I think that it probably should.
PS> (ps (lambda () (try (foo) (:catch (e) e)))) => "function () { try { return foo(); } catch (e) { e; }; };"
- Scott
On 2009-11-04, at 12:57 PM, Vladimir Sedach wrote:
Hello,
Many of you have been asking for this for a long time, and based on feedback (as well as my own experience) the lack of this feature has been the biggest cause of bugs in PS code, so it's with a bit of joy that I just pushed out a patch to add implicit returns to PS functions (including lambdas and flet/labels) to the repository just now. Please try it out and report any bugs you find!
Thank you, Vladimir
_______________________________________________ parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
_______________________________________________ parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
Hi Vladimir, On 2009-11-22, at 12:27 AM, Vladimir Sedach wrote:
I've just pushed a patch that should address all the issues raised so far in this thread. Thank you for the QA Scott!
Thanks Vladimir! One thing I've found in the latest commit is that using SYMBOL-MACROLET in a function tail position seems to thwart implicit return: JS> (ps (lambda () (loop do (+ 2 2)))) "function () { for (; true; ) { 2 + 2; }; return null; };" JS> (ps (lambda () (symbol-macrolet ((x 2)) (loop do (+ x x))))) "function () { return (for (; true; ) { 2 + 2; }, null); };" JS> Regards, - Scott
Just to follow up on this point: < Regarding try/catch, I'm still on the fence. Anyone have try/catch use cases where implicit return is not what would be wanted? > It seems pretty clear to me that there should be implicit return inside CATCH blocks. After all, there is implicit return inside TRY, and by definition, the code was never able to actually execute that return. Something ought to take its place. We have three or four usages where we've had to hack an explicit return back into our PS, just so that an error object makes it out of CATCH. Equally important, it seems to me, is that FINALLY blocks *not* provide implicit return. Either a TRY or CATCH has already specified a return value; FINALLY is usually for tying up loose ends, not overriding the return value. In other words, I think the existing behavior around FINALLY is good. If no one objects, can you go ahead and put implicit return into CATCH so I can take out our hack? Daniel On Sun, Nov 22, 2009 at 12:27 AM, Vladimir Sedach <vsedach@gmail.com> wrote:
I've just pushed a patch that should address all the issues raised so far in this thread. Thank you for the QA Scott!
Regarding try/catch, I'm still on the fence. Anyone have try/catch use cases where implicit return is not what would be wanted?
Vladimir
2009/11/5 <sblist@me.com>:
Vladimir and friends,
In the following example, do you think that both the try block and the handler blocks should receive an explicit return?
I'm not absolutely convinced, but I think that it probably should.
PS> (ps (lambda () (try (foo) (:catch (e) e)))) => "function () { try { return foo(); } catch (e) { e; }; };"
- Scott
On 2009-11-04, at 12:57 PM, Vladimir Sedach wrote:
Hello,
Many of you have been asking for this for a long time, and based on feedback (as well as my own experience) the lack of this feature has been the biggest cause of bugs in PS code, so it's with a bit of joy that I just pushed out a patch to add implicit returns to PS functions (including lambdas and flet/labels) to the repository just now. Please try it out and report any bugs you find!
Thank you, Vladimir
_______________________________________________ parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
_______________________________________________ parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
_______________________________________________ parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
Done. 2009/12/3 Daniel Gackle <danielgackle@gmail.com>:
Just to follow up on this point:
< Regarding try/catch, I'm still on the fence. Anyone have try/catch use cases where implicit return is not what would be wanted? >
It seems pretty clear to me that there should be implicit return inside CATCH blocks. After all, there is implicit return inside TRY, and by definition, the code was never able to actually execute that return. Something ought to take its place. We have three or four usages where we've had to hack an explicit return back into our PS, just so that an error object makes it out of CATCH.
Equally important, it seems to me, is that FINALLY blocks *not* provide implicit return. Either a TRY or CATCH has already specified a return value; FINALLY is usually for tying up loose ends, not overriding the return value. In other words, I think the existing behavior around FINALLY is good.
If no one objects, can you go ahead and put implicit return into CATCH so I can take out our hack?
Daniel
On Sun, Nov 22, 2009 at 12:27 AM, Vladimir Sedach <vsedach@gmail.com> wrote:
I've just pushed a patch that should address all the issues raised so far in this thread. Thank you for the QA Scott!
Regarding try/catch, I'm still on the fence. Anyone have try/catch use cases where implicit return is not what would be wanted?
Vladimir
2009/11/5 <sblist@me.com>:
Vladimir and friends,
In the following example, do you think that both the try block and the handler blocks should receive an explicit return?
I'm not absolutely convinced, but I think that it probably should.
PS> (ps (lambda () (try (foo) (:catch (e) e)))) => "function () { try { return foo(); } catch (e) { e; }; };"
- Scott
On 2009-11-04, at 12:57 PM, Vladimir Sedach wrote:
Hello,
Many of you have been asking for this for a long time, and based on feedback (as well as my own experience) the lack of this feature has been the biggest cause of bugs in PS code, so it's with a bit of joy that I just pushed out a patch to add implicit returns to PS functions (including lambdas and flet/labels) to the repository just now. Please try it out and report any bugs you find!
Thank you, Vladimir
_______________________________________________ parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
_______________________________________________ parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
_______________________________________________ parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
_______________________________________________ parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
Thanks! I've upgraded and removed our return-from-catch hack. A few bits of feedback from the latest round of changes: 1) The generated code for calling setf functions is much cleaner. Whatever you did, it addressed my concern. 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. 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. Daniel On Fri, Dec 25, 2009 at 12:59 AM, Vladimir Sedach <vsedach@gmail.com> wrote:
Done.
2009/12/3 Daniel Gackle <danielgackle@gmail.com>:
Just to follow up on this point:
< Regarding try/catch, I'm still on the fence. Anyone have try/catch use cases where implicit return is not what would be wanted? >
It seems pretty clear to me that there should be implicit return inside CATCH blocks. After all, there is implicit return inside TRY, and by definition, the code was never able to actually execute that return. Something ought to take its place. We have three or four usages where we've had to hack an explicit return back into our PS, just so that an error object makes it out of CATCH.
Equally important, it seems to me, is that FINALLY blocks *not* provide implicit return. Either a TRY or CATCH has already specified a return value; FINALLY is usually for tying up loose ends, not overriding the return value. In other words, I think the existing behavior around FINALLY is good.
If no one objects, can you go ahead and put implicit return into CATCH so I can take out our hack?
Daniel
On Sun, Nov 22, 2009 at 12:27 AM, Vladimir Sedach <vsedach@gmail.com> wrote:
I've just pushed a patch that should address all the issues raised so far in this thread. Thank you for the QA Scott!
Regarding try/catch, I'm still on the fence. Anyone have try/catch use cases where implicit return is not what would be wanted?
Vladimir
2009/11/5 <sblist@me.com>:
Vladimir and friends,
In the following example, do you think that both the try block and the handler blocks should receive an explicit return?
I'm not absolutely convinced, but I think that it probably should.
PS> (ps (lambda () (try (foo) (:catch (e) e)))) => "function () { try { return foo(); } catch (e) { e; }; };"
- Scott
On 2009-11-04, at 12:57 PM, Vladimir Sedach wrote:
Hello,
Many of you have been asking for this for a long time, and based on feedback (as well as my own experience) the lack of this feature has been the biggest cause of bugs in PS code, so it's with a bit of joy that I just pushed out a patch to add implicit returns to PS
functions
(including lambdas and flet/labels) to the repository just now. Please try it out and report any bugs you find!
Thank you, Vladimir
_______________________________________________ parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
_______________________________________________ parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
_______________________________________________ parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
_______________________________________________ parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
_______________________________________________ parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
participants (3)
-
Daniel Gackle -
sblist＠me.com -
Vladimir Sedach