I find it useful to distinguish between unassigned and undefined (null).
"None" is very often a valid value, especially for primitive types, and
especially where databases are involved. i.e., the range of a variable might
be {undef, -2^31..2^31-1}. In my experience:
99 + undef -> 99 # Permissive. Stable. Useful. [Perl]
99 + undef -> undef # Pedantic. Error-prone. Annoying. [SQL, C# 2.0]
99 + undef -> die # Anal retentive. Crash-prone. Enfuriating.
[Obj-C]
99 + undef is impossible # Ill-advised. Unusable. [C#, C]
I find null propagation frustrating; it's more useful that my code keep data
rather than to throw it away on the theory that "undef means maybe, and
anything combined in any fashion with maybe results in more maybe". I just
wind up writing defined(expr)?expr:0 over and over to avoid throwing away
the other part of the expression.
The two third and fourth options are just progressively more destructive
forms of the same logic. Succinctly, 'use crash_on_every_use_of_undef' is an
pragma I'd want to opt out of almost globally.
An unassigned variable is very different, and is a compile-time concept.
Static flow control can find accesses of not definitely assigned local
variables, like this:
my Animal $pet;
given $kind {
when 'dog': $dog = new Dog;
when 'cat': $pet = new Cat;
when 'none': $pet = undef;
}
return $pet;
Static flow control analysis can see that, where $kind not in ('dog', 'cat',
'none'), $pet will not be definitely assigned in the return statement. To
ensure definedness, there must be a default case. Perhaps $pet's
compiler-supplied default value is okay, but the programmer's intent isn't
explicit in the matter. Note that in the case of $kind == 'none', $pet's IS
assigned: It's assigned undef.
While flow control analysis requires some additional work to avoid reliance
on default values, I find that work to be less than the work debugging the
bugs introduced because such checks aren't performed in the first place. It
also allows for very strong guarantees; i.e., "I know this variable cannot
be undefined because I never assign undef to it, and the compiler would tell
me if I accessed it without assigning to it."
This is what 'use strict' should evolve toward, in my mind.
-----Original Message-----
From: Darren Duncan [mailto:[EMAIL PROTECTED]
Sent: Sat, Dec 17, 2005 1:26 AM
To: perl6-language@perl.org
Subject: Re: handling undef better
At 10:07 PM -0800 12/16/05, chromatic wrote:
>On Friday 16 December 2005 18:15, Darren Duncan wrote:
> > 0. An undefined value should never magically change into a defined
>> value, at least by default.
>
>This is fairly well at odds with the principle that users shouldn't
>have to bear the burden of static typing if they don't want it.
This matter is unrelated to static typing. The state of whether a variable
is defined or not is orthoganal to its container type.
>It sounds like you want to override the coercion of undef to fail, at
>least in a lexical scope. Go for it.
Yes. Or have that be the default behaviour.
Just as having variables magically spring into existence on the first
reference to them should not happen by default, and Perl 6 defaults to
having this stricture turned on.
Likewise, it should have the stricture of no undef coersion on by default,
but developers can turn it off locally as they turn off strict locally.
>I can't see it as a default behavior though. Sure, the literal
>expression "6
>+ undef" is pretty silly, but I don't really want to write "6 + Maybe
>$variable" (sorry, Haskellers) everywhere when the compiler is
>perfectly capable of DWIMming in the 98% of cases where $variable is
>undefined because I like being so lazy as not to initialize explicitly
>every possible variable I could ever declare, being very careful to
>distinguish between 0, '', and undef in boolean context.
>
>I suspect the remaining two percent of cases, I won't write "6 + undef"
>either.
I think you're over-stating the frequency of situations where people
actually want that auto-coersion; I'm thinking it is more like 50% at best.
But more to the point, if you assign your default values at strategic
places, you are not writing very much extra code at all.
I find the argument against assigning explicit values to be only slightly
stronger than the argument against using 'my' etc.
Those few characters are nothing considering the amount of hassle they can
save.
-- Darren Duncan
