On Sun, Mar 27, 2005 at 12:04:39AM -0500, Uri Guttman wrote:
: >>>>> "LW" == Larry Wall <[EMAIL PROTECTED]> writes:
:
: LW> As I mentioned in my other message, I think we should not assume that
: LW> Perl 6 works the same in this regard as Perl 5 does. There needs to be
: LW> something we can return that not only means (), but means also means
: LW> "You're hosed! (And here's why.)" And I think we can make undef mean
: LW> that if we make it lazily sensitive to scalar/list context (much like @a
: LW> itself can be lazily sensitive to context).
:
: LW> Hmm, maybe it would simpler to just tell everyone undef is a special
empty
: LW> lazy array that refuses to produce a value no matter how you ask.
:
: why use undef for the error code?
Because there's usually a reason why the undef was created, and it would
be useful for the user to learn that.
: isn't this what exceptions are for?
Undef is a form of unthrown exception. Throwing things is often too
violent for fail-soft situation.
: or setting $!?
$! is the current unthrown exception in Perl 6. (Or actually, it's also
the thrown exception inside a CATCH block.)
: i actually use naked return as a postive thing in stem
: (string return values are bad and have the error string. it is
: consistant so it works).
Okay, so in this case you could hack around the problem because you don't
want to return interesting "good" values. But sometimes you have both
interesting good values and interesting bad values. "Interesting" values
of undef solves that problem without having to send either the good data
or the bad data out of band.
: the problem with returning undef (or naked
: return) is that it is in-band data. now you could do a naked return but
: error thing. and then the called has to check for that property each
: time.
You should be checking your return values anyway, or useing "fatal", which
turns these unthrown exceptions into thrown ones.
: but what does that mean when you do this (bad p6 code):
:
: sub return_error { return but error }
That's written:
sub return_error { fail "What went wrong" }
which has the effect of
sub return_error { return undef but Exception("What went wrong") }
unless the caller uses "fatal", in which case it's more like
sub return_error { die("What went wrong") }
: my @a = return_error() ;
:
: is @a empty or what? how do you see the error in @a?
I am proposing that assigning a exceptional undef value (such
as that returned by fail() above) to an array causes the array to
become undefined. If you use that array somewhere else, it's as if
you used the original unthrown exception. Eventually you get caught
trying to do something defined with the undefined value and you get
a nice message out saying where the original undefined value came from.
: i just don't like seeing undef used for error handling as it has too
: many other uses (even if i did it in stem).
I don't see how the proposed semantics interfere with any other uses of
undef. A bare scalar undef is still a very simple value. I don't see
how you can simultaneously argue that it has many uses and yet has only
one simple value.
: just make undef a scalar value and not a function nor a error marker.
fail("Language designer not persuaded"); # :-)
Larry
