On Wed, Aug 6, 2008 at 8:58 AM, Yaakov Belch <[EMAIL PROTECTED]> wrote:
> In a little language that I wrote some time ago, I found it very useful to
> let the // operator catch exceptions:
>
> f(x) // g(y) does:
> * If f(x) returns a defined value, use this value.
> * If f(x) returns an undefined value, use the value of g(x) instead.
> * If f(x) throws an exception, catch and keep it in $!, use the value of g(x)
> * But don't catch exceptions of g(x).
>
> Similarly, f(x) // g(y) // h(z) catches exceptions of f(x) and of g(y)
> but not of h(z).
>
> I would like to suggest the same semantics for perl6.
>
> Let me explain why this is useful and why I think this is "the right thing":
> First of all, it provides a very light-weight exception handling using
> well-known ideoms like:
> $file_content=read_file($filename) // $default_value;
> compute_statistics($data) // write_log_message("stats failed: $!");
>
> With the proposed change, these ideoms work whether the functions throw
> exceptions or not.
>
> But why should this be the "right thing"? Obviously, // is the "fallback"
> or "redundancy" operator: Don't despair if the first computation doesn't
> produce a usable result --- we have another way of getting the job done.
> In this context, and exception conveys the same message as an undefined
> value: The first step failed. You need to fall back to some other
> alternative or give up! As the second expression provides exactly this
> other alternative, there is no need to jump out of the normal processing
> order anymore.
>
i don't think this will work for perl 6. since perl 6 has resumeable
exceptions (like C<warn>), the meaning of the C<//> operator could be
ambiguous. given the following statement,
my $bill = ack() // thpp() // ppt();
with perl 6's current semantics, if C<ack()>, throws a resumable
exception that is handled in the current scope or an outer scope,
execution will resume before C<//> and the definedness of the result
from C<ack()> will be tested in order to determine whether or not to
call C<thpp()>.
using your semantics, if a resumable exception is thrown in C<ack()>,
C<//> will cause C<thpp()> to be invoked immediately, discarding any
possible defined result from C<ack()>. also, the question arises that
if C<thpp()> doesn't handle the type of exception thrown, should
C<ppt()> be called immediately, or only if C<thpp() returns an
undefined result? seems to me it would try to handle the exception
thrown by C<ack()>. so how do i signify that my exception has been
handled, and that i can now assign a default value to C<$bill>?
in my mind, this strays too far from the meaning of C<//> and adds
ambiguity that makes the operator unusable. perhaps there's room for
an operator that gives some sugar for
my $bill = try { ack() CATCH { thpp() } };
but to me that code is concise enough that it doesn't warrant syntactic relief.
~jerry
