Re: eval and try should be separate

[Carl Mäsak]

+1

It's been up for discussion before in #perl6 (with a quick search, I
find  and
), 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  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

[Larry Wall]

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

[noreply]

  Branch: refs/heads/master
  Home:   https://github.com/perl6/specs

  Commit: e84b11137cc55ecd9f17f58976c08d361054ea05
  
https://github.com/perl6/specs/commit/e84b11137cc55ecd9f17f58976c08d361054ea05
  Author: Moritz Lenz 
  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"

[noreply]

  Branch: refs/heads/master
  Home:   https://github.com/perl6/specs

  Commit: 781e7266ed8dd7e948e640142462fe48736a2d56
  
https://github.com/perl6/specs/commit/781e7266ed8dd7e948e640142462fe48736a2d56
  Author: Larry Wall 
  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 
  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 
  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 C and C 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