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
