[perl6/specs] e8bea7: s// -> s/// from jlaire++
Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: e8bea71b6d8799febb5070dd4b36afa842695699 https://github.com/perl6/specs/commit/e8bea71b6d8799febb5070dd4b36afa842695699 Author: Larry Wall Date: 2011-06-29 (Wed, 29 Jun 2011) Changed paths: M S05-regex.pod Log Message: --- s// -> s/// from jlaire++
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?
