On 12/16/05, Darren Duncan <[EMAIL PROTECTED]> wrote:
> Something else I've been thinking about, as a tangent to the
> relational data models discussion, concerns Perl's concept of
> "undef", which I see as being fully equivalent to the relational
> model's concept of "null".

The relational model doesn't have a concept of NULL. SQL has a concept
of NULL which many relational theorists feel is completely bad.

The way to look at NULL is as a CodeSmell saying "I haven't normalized
this data enough."

> Therefore, I propose that the default behaviour of Perl 6 be changed
> or maintained such that:
> 0. An undefined value should never magically change into a defined
> value, at least by default.

Fold this into strictures. Instead of this, there should be a
stricture for it. "use strict 'undef';" sounds nice.

> 1. Any expression that expects a defined value as an argument, such
> as typical mathematical or string operations, and gets an undefined
> argument, will as a whole have undef as its value, or it will fail.
> Examples are the expressions "$anything + undef" and "$anything ~
> undef".
> 1a. If such an expression will always return a value, the value is undef.
> 1b. If the expression is allowed to fail, it can do that instead.

I'm not sure I want to see the NaN fallacy in Perl6. Since every
operation is allowed to fail through throwing an exception, I'd argue
that this should be the case under strict 'undef'.

> 2. Any boolean-returning expression should return undef or false or
> fail if given an undef.
> 2a. At the very least, "undef <equality-test-op> undef" should NEVER
> return true, because an unknown quantity can not be claimed to be
> equal to an unknown quantity.  Rather, the defined() method, which is
> analagous to 'IS NOT NULL', and such things are the proper way to
> test if a variable is unknown.
> 2b. As a pseudo-exception, while undef/unknown values are
> conceptually all unequal to each other, they should all sort
> together; eg, calling sort() on an array of values where some are
> defined and some not, should group all the undefs together.  I leave
> it up to discussion as to whether they should sort before or after
> all the defined values, but one of those choices should be picked for
> predictability.

How many different undefs are there?


> The fact is, that in any normal program, using an undefined value as
> if it were a defined one is a bug. . . .

Many times, I've treated undef as 0 or '' in little scripty-doos,
simply because it's easier to do it that way. I think that this
behavior (which is desirable) and the behavior you're describing
(which is desirable) is easily handled by a new stricture.

> Now, in the spirit of TMTOWTDI, such as for people that like to turn
> strictures or warnings off, I suggest that there can be an optional
> feature, perhaps a pragma or better a core module, where a developer
> can say that they want undefs to automatically become zero in numeric
> contexts or an empty string in string contexts, or false in boolean
> contexts, etc.  But they should have to explicitly activate that
> feature, like saying "treat undef as 0 in all my code", and this
> treating would not happen by default.

No - a stricture. :-)


Reply via email to