in reply to Re^3: A bit more clarity on uninitialized value in string ne (init vs def)
in thread A bit more clarity on uninitialized value in string ne

tye, you're just picking the nits in a different way. And, to be honest, I've never thought about "undef" as "uninit". In more general computer science terms, I would expect:

my $t; # perl int* pi; // C/C++
to be uninitialised. But I would expect:
my $t = undef; # perl int* pi = NULL; // C/C++
to be initialised but not really usuable. The fact that perl guarantees that uninitialised variables are undef allows the semantics you're arguing for, that they mean the same thing in perl, but that just seems to be an accident due to a feature.

I don't think I would really be in favour of having the perl runtime distinguish between undef and uninitialised - that's just more code to run in lots of places, and would likely break another feature of perl: autovivication. Just as simply assigning to $h{blah} will create the blah key, shouldn't using $a automatically initialise ... to undef? IMNSHO, fixing the error message is sufficient. And all that would break is the test suite for perl itself ... and a few other modules that catch warnings and respond to them (in other words, I understand why it's not being fixed).

What we probably should be doing is giving our error messages and warnings a prefix tag that our code can look for instead. Rather than "Use of uninitialized value in ...", why not "PERL0183W: Use of uninitialized value in ..."? With the latter, we can change the text all we want, as long as the prefix stays the same. All tests, signal handlers (for __WARN__ and __DIE__), and $@ checks could simply look for /^PERL0183W:/, and text changing won't affect them. I realise that the majority of error and warning messages won't change. But by having it as a standard for all internal messages, we won't need to worry about the ones that do need change.


NOTE: if the original post had "use diagnostics", it would tell you that "an undefined value was used as if it were already defined." Then this whole thread might have been averted, and I would not have had to tell Ovid to calm down ;-}

Replies are listed 'Best First'.
Re^5: A bit more clarity on uninitialized value in string ne (init vs def)
by tye (Sage) on Jan 21, 2005 at 16:30 UTC
    The fact that perl guarantees that uninitialised variables are undef allows the semantics you're arguing for, that they mean the same thing in perl, but that just seems to be an accident due to a feature.

    No, I'm pretty sure that Perl guarantees that uninitialized variables are undef because that was the point of undef and defined and having a warning for trying to get a string or number from undef. The point was to offer ways of tracking uninitialization. That is why, when the person was writing the text for the warning for "you used undef" pulled out the word "uninitialized", because that was the concept motivating the whole exercise.

    - tye