Re: What happened to err operator?
HaloO,
On Thursday, 4. September 2008 03:39:20 Larry Wall wrote:
Another potential issue is that CATCH doesn't distinguish exceptions
coming from the current block from those coming from the subcall to a().
So it could end up returning Failure from the current block when
you intended to force return of Failure from a(). Not sure what
to do about that...
I don't understand this issue. I think we have the fact that
*every* operator is at least conceptually dispatched and as
such everything in a block is at least one level down in the
call chain just as a() as a sub call is. This is why a CATCH
block inside the block is so natural to me.
If I understand your intention correctly you want to be able
to force a thrown exception from a() into a returned value
and proceed where this return value is supposed to show up
in the current block, right? The simplest solution that comes
to my mind is some form of goto to that position. Or is that
too inelegant? The point is how the CATCH block knows from
which subordinate scope the exception originates.
a() proceed: orelse b();
CATCH
{
... # make $! into return value
goto proceed;
}
This kind of needs to know the variable the return value of a()
is stored into. This is easy if orelse is checking $! anyway.
But does it? And is it possible to have labels in the middle
of a line as above?
Regards, TSa.
--
The unavoidable price of reliability is simplicity -- C.A.R. Hoare
Simplicity does not precede complexity, but follows it. -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: What happened to err operator?
TSa (Thomas Sandlaß) schreef:
Larry Wall:
Another potential issue is that CATCH doesn't distinguish exceptions
coming from the current block from those coming from the subcall to
a(). So it could end up returning Failure from the current block when
you intended to force return of Failure from a(). Not sure what
to do about that...
I don't understand this issue. I think we have the fact that
*every* operator is at least conceptually dispatched and as
such everything in a block is at least one level down in the
call chain just as a() as a sub call is. This is why a CATCH
block inside the block is so natural to me.
If I understand your intention correctly you want to be able
to force a thrown exception from a() into a returned value
and proceed where this return value is supposed to show up
in the current block, right? The simplest solution that comes
to my mind is some form of goto to that position. Or is that
too inelegant? The point is how the CATCH block knows from
which subordinate scope the exception originates.
a() proceed: orelse b();
CATCH
{
... # make $! into return value
goto proceed;
}
This kind of needs to know the variable the return value of a()
is stored into. This is easy if orelse is checking $! anyway.
But does it? And is it possible to have labels in the middle
of a line as above?
Maybe the = should deliver the normal (=value) part of the
return-stash, and a different deliverer should be used to get other
information out of it.
--
Affijn, Ruud
Gewoon is een tijger.
Re: What happened to err operator?
TSa (Thomas Sandlaß) thomas-at-sandlass.de |Perl 6| wrote:
a() proceed: orelse b();
CATCH
{
... # make $! into return value
goto proceed;
}
This kind of needs to know the variable the return value of a()
is stored into. This is easy if orelse is checking $! anyway.
But does it? And is it possible to have labels in the middle
of a line as above?
No, I think code in the CATCH could look at its context/callers and
issue a return from the proper one, that is the call to a().
In particular, it can be done using only the conceptual primitives.
Adding an easy way is just library code, not more primitive concepts
that need to be supported.
In particular, I'd like to have an easy way to get that particularly
interesting context (a special word used for the smart match syntax in
the existing context/caller mechanism) and a fail-as-return method on $!
that encapsulates all that, but always works right and efficiently even
in the face of optimization.
--John
Re: What happened to err operator?
On Wed, Sep 03, 2008 at 06:41:10PM -0500, John M. Dlugosz wrote:
Larry Wall larry-at-wall.org |Perl 6| wrote:
a() orelse b()
you might want to:
succeed on a()
trap mild failure of a() and try to succeed on b() instead
fail completely on drastic failure of a()
At the moment this three-way distinction depends on whether a() returns
defined/undefined or throws an exception. Maybe that's good enough.
I don't want to overcomplexify things, but I don't want to
undercomplexify them either. :)
I'm thinking that, rather than have a zillion options to pre-configure
the fail mode of that group of functions, it can be done by having a
CATCH handler that calls resume on the ones you want to pop back out.
{ # some block scope
use fail;
a() orelse b();
more-stuff-here;
CATCH {
when xxx { .resume() }
}
I think .resume is not quite right, since resume would tell the fail
to return back into the body of a() as if it were merely a warning.
(Which is how we do warnings, after all.) We need a name for what fail
does when fatal isn't turned on, which might simply be a .return(),
though that's going to be confusing to people who think it returns
from the outer routine rather than from a(). So maybe we should give
it an obscure name like .interesting() or some such to turn a thrown
exception into a mere interesting value of undef.
Presumably a failure that is returned rather than thrown is already
considered interesting. :)
I suppose some will be inclined to turn on use fatal and defatalize
everything with .interesting, though I'm pretty certain that would
not be nearly as efficient as if fail just returned directly.
Another potential issue is that CATCH doesn't distinguish exceptions
coming from the current block from those coming from the subcall to a().
So it could end up returning Failure from the current block when
you intended to force return of Failure from a(). Not sure what
to do about that...
This is also handy in that you can set flags or something before getting
back to the main expression. This makes EH more like a footnote to
the code than anything I've used before.
Indeed, nice metaphor.
Larry
Re: What happened to err operator?
On Sun, Aug 31, 2008 at 04:28:36PM -0500, John M. Dlugosz wrote: Has the err operator, as a low-precidence version of //, been removed? Yes. It could be recycled as a fuzzy Boolean, returning a fractional value between +1 and -1, indicating the confidence with which the result is offerred. (As in err, I'm not sure. :-)* ) -- Email and shopping with the feelgood factor! 55% of income to good causes. http://www.ippimail.com
Re: What happened to err operator?
I think you're thinking of the erm operator... But back to orelse - is the only difference between and/or and andthen/orelse the fact that the result of the lhs gets passed as a parameter into the rhs? 'Cause I don't see the difference between short circuit and proceed on success/failure. On 9/2/08, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Sun, Aug 31, 2008 at 04:28:36PM -0500, John M. Dlugosz wrote: Has the err operator, as a low-precidence version of //, been removed? Yes. It could be recycled as a fuzzy Boolean, returning a fractional value between +1 and -1, indicating the confidence with which the result is offerred. (As in err, I'm not sure. :-)* ) -- Email and shopping with the feelgood factor! 55% of income to good causes. http://www.ippimail.com -- Sent from Gmail for mobile | mobile.google.com Mark J. Reed [EMAIL PROTECTED]
Re: What happened to err operator?
On Tue, Sep 02, 2008 at 07:56:33PM -0400, Mark J. Reed wrote:
: I think you're thinking of the erm operator...
:
: But back to orelse - is the only difference between and/or and
: andthen/orelse the fact that the result of the lhs gets passed as
: a parameter into the rhs? 'Cause I don't see the difference between
: short circuit and proceed on success/failure.
They're also different in the sense that and/or are boolean tests
while andthen/orelse are definedness tests, as currently specced.
For logic programming purposes, though, it's possible that we'll end
up with something in between, because in addition to distinguishing
success from failure, we may wish also to distinguish expected failure
(normal regex backtracking, for example) from unexpected failure
(abject parser failure, for example). In other words, when you say
a() orelse b()
you might want to:
succeed on a()
trap mild failure of a() and try to succeed on b() instead
fail completely on drastic failure of a()
At the moment this three-way distinction depends on whether a() returns
defined/undefined or throws an exception. Maybe that's good enough.
I don't want to overcomplexify things, but I don't want to
undercomplexify them either. :)
In the limit, one might want the entire power of a CATCH block on
the right side of orelse. Currently you'd have to write:
a() orelse do given $! {
when MajorMalfunction { die oopsie }
when * { b() }
}
or some such. Nest a few of those and it makes more sense to say
a() orelse
b() orelse
c() orelse
d() orelse
e();
CATCH {
when MajorMalfunction { die oopsie }
}
assuming that exceptions somehow get returned or thrown appropriately.
I suppose orelse could itself throw any exception that it doesn't want
to treat as benign, and the CATCH block would handle it. And the
definition of benign could then be pragmatically controlled if the
default wasn't good enough, I suppose.
Larry
Re: What happened to err operator?
On Sun, Aug 31, 2008 at 04:28:36PM -0500, John M. Dlugosz wrote: Has the err operator, as a low-precidence version of //, been removed? Yes. It's not mentioned in S03, and the semantics of orelse is different. Is orelse supposed to be a direct replacement, meaning if you ignore the parameter thing then it doesn't change anything? You can use it the same way, but if you think of // and orelse as the same operator at different precedence, it's not quite the reality. I don't believe there is such a thing as a defined-or operator. I think of // instead as a default operator, and as such it's primarily useful at a precedence tighter than infix:=, and it almost never cares about *why* the left side is undefined. The orelse operator is aimed at logic programming, not defaulting, and in logic programming the right side can often have additional dependencies on the left side. It's almost an accident that both operators care about whether the left side is defined. (This is also why there is no tight version of andthen.) Of course, there's more to it than that. Politically, it's a kind of compromise between p5p and me. I hated their dor operator, and p5p by and large hated the err operator. The result was that we switched to orelse and they dropped dor. So the preceding paragraph can be construed as a mere rationalization of why the sausage came out of the sausage factor green this time. :) Larry
