On Wed, Nov 26, 2003 at 11:39:41AM -0800, Michael Lazzaro wrote:
: On Monday, November 24, 2003, at 03:28 PM, Luke Palmer wrote:
: >Damian Conway writes:
: >>In which case I think we just fall back to:
: >>
: >> try{$opus.write_to_file($file); CATCH {die "Couldn't write to
: >>$file:
: >> $!"}}
: >>
: >>which is, after all, only 5 characters longer than:
: >>
: >> $opus.write_to_file($file) catch die "Couldn't write to $file:
: >>$!\n";
: >>
: >>;-)
: >
: >Fair enough :-)
: >
: >No, I wasn't implying that C<write_to_file> could validly return undef.
: >I just failed to realize how short the "long" version was.
: >
: >But you have to admit, the latter version makes the important part of
: >the expression stand out, and is more natural to write (IMHO, as
: >always).
: >
: >But it's moduleable, so I won't worry about it.
:
:
: A small point of order, philosophically...
:
: While there is a justifiable urge to deny entry into of the core
: language of as much syntactic sugar as possible -- since merely looking
: at the operator list proves P6 will be a behemoth of a language, when
Only if you "unroll" all the composite operators formed of a base operator
and a modifier...
: you consider all of its nooks and crannies -- I think we also need to
: be skeptical of the false economy of putting such sugar into CP6AN, if
: a sizable portion of the community is going to download it anyway.
:
: In my mind, Luke's proposed C<catch> modifier quite easily fits the
: qualifications of something that should be in core, for the following
: reasons:
:
: - It serves a common purpose, for which there is Only One (Good) Way To
: Do It. While you perhaps _can_ say
:
: try {
: $opus.write_to_file($file);
: CATCH {
: die "Couldn't write to $file: $!"
: }
: }
:
: in other golfish ways, the above is clearly (ignoring preferences in
: whitespace formatting) the Obvious and Recommended way to do it, and so
: the above phrase will appear _wherever_ a single statement needs to be
: wrapped with a try/CATCH.
Well, ignoring the fact that the routine should really be returning undef
for an anticipated failure...
: - It has one, and only one, obvious meaning. Nobody should be making
: their own 'catch' modifiers that do different things -- that would be
: far more annoying, for shared code, than reserving the keyword in
: advance to do the One Obvious Thing.
By that argument we end up with 1000 keywords.
: - It is consistent with the philosophy of similar syntax.
I don't see how.
: - It poses no significant harm to novice users. They can program in P6
: effectively without ever using it, but if they do see it in someone
: else's code, it will be reasonably obvious what it is doing. And
: whether it is core or commonly used CP6AN, they _will_ see it in other
: people's code.
I don't think so. See below.
: It is true, the difference between the two constructs:
:
: try { $opus.write_to_file($file); CATCH {die "Couldn't write to
: $file: $!"} }
:
: $opus.write_to_file($file) catch die "Couldn't write to $file: $!";
:
: is only 7 characters. But four of those characters are curly brackets,
: visually introducing two blocks. That's kind of a yuck.
If you contrast it with an explicit try block, sure, it looks better. But
that's not what I compare it with. I compare it with Perl 5's:
$opus.write_to_file($file) or die "Couldn't write to $file: $!";
That has some known problems with false positives, er, negatives,
which Perl 6 addresses with things like:
$opus.write_to_file($file) err fail "Couldn't write to $file: $!";
But if we're going to talk about philosophy, we should talk about
Perl's notion of not forcing people to escalate all the way to
exceptions when a lesser form of undefinedness or falseness will do.
Perl 6 doesn't back off from this. In fact, it takes it further
by allowing you to return unthrown exceptions as "undef". And by
providing a "fail" that either returns or throws the exception
depending on the preferences of the caller.
If you want to promote a catch modifier to me, you'd better market it
as a form of "or" rather than a form of "try". I could see a form
of "err" that implies a try around its left argument and coerces
any caught exception to an undef exception. But that sounds like
a philosophical decision to be made consistently by the calling
module. like "use fatal" in reverse. So I think I'd rather see a
pragma that does that to "err" instead of adding yet another keyword.
Larry
