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

undef is how Perl designates that a variable is uninitialized. undef $var is how you declare that the variable is no longer initialized. $var= undef does the same thing.

If you try to disinguish 'undef' from 'uninitialized', then you'd need a new way to deinitialize variables and an alternative for defined that would tell you if a variable was initialized.

undef and defined are just Perl's methods of introspection about whether a variable is initialized. It is good that you can explicitly mark a variable as uninitialized and that you can programmatically check for initialization. Marking a variable as uninitialized can look like initializing the variable.

I agree that using "uninitialized" instead of "undefined" in error messages is unfortunate. But they mean the same thing in Perl.

- tye

Comment on Re^3: A bit more clarity on uninitialized value in string ne (init vs def) Select or Download Code

Replies are listed 'Best First'.
Re^4: A bit more clarity on uninitialized value in string ne (init vs def) by Tanktalus (Canon) on Jan 21, 2005 at 16:20 UTC
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++` [download] to be uninitialised. But I would expect: `my $t = undef; # perl int* pi = NULL; // C/C++` [download] 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 ;-}	[reply] [d/l] [select]
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	[reply]