Re: eval and try should be separate
+1 It's been up for discussion before in #perl6 (with a quick search, I find http://irclog.perlgeek.de/perl6/2011-06-03#i_3851753 and http://irclog.perlgeek.de/perl6/2011-05-07#i_3688404), but so far no-one has acted on the idea. Kudos for picking it up. // Carl On Wed, Jun 29, 2011 at 10:44 PM, Stefan O'Rear stefa...@cox.net wrote: I intend to change the definition of eval such that it does not catch exceptions. String eval's role as the catcher of exceptions is a legacy of Perl 1, which had no block eval, and I feel it has no place in Perl 6. The exception catching and associated unwinding makes it impossible to use resumable exceptions across eval boundaries. This includes warn. Given an eval that does not catch exceptions, it is very easy to add catching, using the new blockless form of try, try eval $code. However, given an eval which does catch, it is impossible to synthesize one that passes exceptions faithfully. Catching exceptions in an eval causes the eval frame to be different from the calling frame, which makes tail call optimization through evals impossible. With the catching eval, it is very easy to write code which accidentally discards exceptions. For the goal of safety it seems best to make discarding exceptions hard by default. Does anyone have objections? Is there general consensus that this change should be made? -Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk4LjqQACgkQFBz7OZ2P+dIKVQCfXaqXIo7JWJOpUNB1jtIOhGS/ sgMAoLu2HjlHMZth8U/7el4XKymLX6Qu =1ywK -END PGP SIGNATURE-
Re: eval and try should be separate
Given that try can be used with a statement as well as a block, I'm fine with this. We want to discourage people from using eval anyway, so forcing people to use 'try eval' to get p5 behavior is okay too. Larry
[perl6/specs] e84b11: eval() does not catch exceptions
Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: e84b11137cc55ecd9f17f58976c08d361054ea05 https://github.com/perl6/specs/commit/e84b11137cc55ecd9f17f58976c08d361054ea05 Author: Moritz Lenz mor...@faui2k3.org Date: 2011-06-30 (Thu, 30 Jun 2011) Changed paths: M S29-functions.pod Log Message: --- eval() does not catch exceptions
[perl6/specs] 781e72: Revert fix 0 = $arg naminess
Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: 781e7266ed8dd7e948e640142462fe48736a2d56 https://github.com/perl6/specs/commit/781e7266ed8dd7e948e640142462fe48736a2d56 Author: Larry Wall la...@wall.org Date: 2011-06-30 (Thu, 30 Jun 2011) Changed paths: M S06-routines.pod Log Message: --- Revert fix 0 = $arg naminess This reverts commit 0140a6f03e1e0917c103eaf730cfafa3c97c8069, which was widely reviled. Commit: e881c784d657bc70127078d5c81a2bdfc5ebca0c https://github.com/perl6/specs/commit/e881c784d657bc70127078d5c81a2bdfc5ebca0c Author: Larry Wall la...@wall.org Date: 2011-06-30 (Thu, 30 Jun 2011) Changed paths: M S06-routines.pod Log Message: --- Revert don't include positional names in API This reverts commit 74b208c3d7dc6bc3fb913be3376492e2d72733f6, which which was found wanting. Commit: 94d01246e7d286bb2a4df32ba9c2ba733d0aec04 https://github.com/perl6/specs/commit/94d01246e7d286bb2a4df32ba9c2ba733d0aec04 Author: Larry Wall la...@wall.org Date: 2011-06-30 (Thu, 30 Jun 2011) Changed paths: M S06-routines.pod Log Message: --- severely restrict named-to-positional binding Binding named args to positional parameters is now restricted to explicit Cproto and Conly declarations. But we will support it, since it can have profound refactoring advantages if you don't have to know which parameters will eventually end up as positionals. Compare: https://github.com/perl6/specs/compare/e84b111...94d0124
