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.
Best regards --- and many thanks for the continued effort on perl6!
Yaakov Belch
