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? [snip] > 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. :-) Rob
