On Fri, Dec 06, 2002 at 05:01:21PM -0500, Dan Sugalski wrote:
> It is OK for an undef value to be true, though. That's not only
> allowable, it has to be allowed. For perl, at least, it's how Larry
> plans on getting around the "function returns undef, but it's a real
> undef value, not a false 'I didn't work' value" issues we have in
> perl 5 now.
Are you sure you want to spell that concept "true"?
Because then if &foo can legitimately return numbers, strings and undefs
does it return
"pie" "pie"
2 2
undef: undef but true,
0 0
"" ""
so now
if (&foo(...)) {
warn "Bang!"
}
warns on traditional true values, and undef?
So the caller then needs to launder the true property from undef before putting
it somewhere else? That feels like a pain.
Or does it return
"pie" "pie"
2 2
undef: undef but true,
0 0 but true
"" "" but true
which makes
if (&foo)) {
warn "Bang!";
}
consistently noisy?
It seems to me that the distinction between intentional undef and failure
undef needs to be made with some property other than "true". It feels like
the distinction between doesn't exist and exists but undef in a hash, the value
returned off the end of an array, or (maybe) the different between the empty
list () and the list (undef)
undef but valid. Or maybe undef but invalid for the failure case?
[so that by default things have no properties]
It's like the argument about the meaning(s) of NULL in SQL, isn't it?
"I just don't know", "known - this isn't applicable" and "this isn't valid"
This is more a perl6 language message, isn't it? If it can't quickly be
quashed, should it migrate there?
Nicholas Clark
--
Befunge better than perl? http://www.perl.org/advocacy/spoofathon/
