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
eval and try should be separate
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 diff --git a/S29-functions.pod b/S29-functions.pod index 21a0cc4..9459036 100644 --- a/S29-functions.pod +++ b/S29-functions.pod @@ -226,7 +226,9 @@ for C$lang would usually do to input files. The default for C$lang is the language in effect at the exact location of the eval call. -Returns whatever C$code returns, or fails. +Returns whatever C$code returns. If C$code generates an exception, +that exception will be propagated, unlike Perl 5. Use try eval if +you want to catch exceptions. =item evalfile signature.asc Description: Digital signature
Re: eval and try should be separate
I agree with the change. Let try be for exceptions and eval be for runtime compile+run of code. These are very distinct concepts and should be separate. -- Darren Duncan Stefan O'Rear 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?
