Re: "undef" is not NULL and what to do about it

So, between the ambiguity of Perl's "undef" and the clarity of SQL's NULL...

You take an interesting position there. "Interesting" in that I've previously debated the merits of SQL's NULL with people who hold that it meaning is ambiguous in exactly the same ways that you say undef is ambiguous. (Does NULL mean that the value is unavailable? Unknown? Inapplicable? Something else?)

Personally, I think that both undef and NULL are fine as they are. Even if you split them into a flock of distinct not-a-values, at least one not-a-value will always be a catch-all for cases that fall outside the set of explicit not-a-values, so the ambiguity will always exist. Yes, the use of explicitly-defined not-a-values would reduce the need to use ambiguous not-a-values, but that comes at the cost of complexity in remembering how the various not-a-values interact and deciding which one to use in any given situation. Far better, IMO, to keep the syntax simple with a single not-a-value, relying on the programmer to indicate its meaning in any given situation and determine the appropriate behavior based on that meaning.

Comment on Re: "undef" is not NULL and what to do about it Select or Download Code

Replies are listed 'Best First'.

Re^2: "undef" is not NULL and what to do about it
by Ovid (Cardinal) on Feb 22, 2013 at 20:09 UTC

Ah, bugger. I should have been more clear. You're absolutely right that it's very unclear what a given NULL should mean. What I meant was that the behavior of NULL is very clear and predictable, regardless of meaning. There are rare cases where you get a false negative, but unlike undef, you generally don't get a false positive. That's a trade-off I prefer, though I can see that many others don't.

Cheers,
Ovid

Live and work anywhere in the world.

The official Perl 6 wiki.

[reply]


laziness, impatience, and hubris
	PerlMonks