Front page | perl.perl5.porters |
Postings from November 2009
Quoth jand@activestate.com (Jan Dubois): > On Mon, 02 Nov 2009, Ben Morrow wrote: > > Is there any point going over all this again? Removing 'err' was > > considered to be a Rule 1 decision, so unless that changes we're not > > doing anything but stirring up old muck. > > The decision was not just to remove "err", but also to add "andthen" > and "orelse" with slightly different semantics. Rafael wrote: Right. > | Larry decided to rename err to orelse in Perl 6. (with a few changes, > | irrelevant to Perl 5, see the perl6-language mailing list.) Also, a > | new operator andthen has been added. See synopsis 3. > | > | That makes err obsolete. So, I'll remove it from Perl 5.10. > | > | orelse and andthen can wait a further release to be added (as a > | feature in the sense of feature.pm) to Perl 5. > > http://www.nntp.perl.org/group/perl.perl5.porters/2007/09/msg128324.html > > So we could revive "dor" as "orelse". The question is, would we also > have to implement the assignment to $! as well? In the case of Perl 5, it would be $@, not $!. The assignment is key to the operator's usefulness: it effectively becomes a shorthand way of writing a try/catch block. > | test1() orelse test2() orelse test3() ... > | > | Returns the first argument that evaluates successfully (that is, > | if the result is defined). Otherwise returns the result of the > | right argument. > | > | If the right side is a block or pointy block, the result of the left > | side is bound to any arguments of the block. If the right side is > | not a block, a block scope is assumed around the right side, and the > | result of the left side is implicitly bound to C<$!> for the scope > | of the right side. > > http://svn.pugscode.org/pugs/docs/Perl6/Spec/S03-operators.pod > > I have to admit that I don't actually understand the spec though: > the right side would only be evaluated when the left side is undef, > so wouldn't $! always be set to undef (and therefore 0)? Perl 6 has the concept of objects that are not defined. In particular, unthrown exception objects are never defined, and the usual (under some settings of 'use fatal', IIRC) way for functions to fail is to return such an unthrown exception which the caller can promote to a full exception by throwing it, without losing the information about where the original error was. There is also a whole lot of other stuff about try blocks pushing previously-unthrown exceptions onto $!.pending (I guess that would become @@ in Perl 5). It's a rather elegant system, but I'm not sure how easy it would be to stuff into Perl 5. It would certainly be a lot more work than simply reviving the 'dor' part of Merijn's patch and renaming the operator. I have had vague thoughts about where one might begin, starting with implementing @@ (which could also catch exceptions thrown from DESTROY, eliminating that problem), but I suspect that attempting to overload definedness would cause too many problems to be worth trying. What I would really like to see is some way for autodie to provide an err-like operator, so that functions can simply return an autodie::exception and callers can choose to throw it or handle it as they see fit. (This would end up almost but not quite entirely unlike the old :void mode of Fatal, which autodie doesn't support.) Perhaps Zefram's patch (assuming the rest of the pieces needed to make it sane can be got into place) might help with something like that. BenThread Previous | Thread Next