Closed p5pRT closed 20 years ago
Trying to print out some debugging info with the following statement: print "targets($tgt) -> targets(@targets) -> '$dest' (@dest)";
Produces the following (IMHO strange) output: Use of uninitialized value in concatenation (.) at ..//Perlbug/Email.pm line 815
The actual string looks like this: targets() -> targets(unix win32 module generic macos) -> '' (perlbug@perl.org perl-win32-porters@perl.org modulebug@perl.org perlbug@perl.org macperlbug@perl.org)";
OK\, there's blank values there\, but where's the concatenation or is it one of these healthy (clear) implicit things? Uninitialised warnings under 'strict' I can follow\, but this appears a bit strange?
Can anyone enlighten me on this?
On Mon\, 3 Apr 2000\, Richard Foley wrote:
Trying to print out some debugging info with the following statement: print "targets($tgt) -> targets(@targets) -> '$dest' (@dest)";
Produces the following (IMHO strange) output: Use of uninitialized value in concatenation (.) at ..//Perlbug/Email.pm line 815
The actual string looks like this: targets() -> targets(unix win32 module generic macos) -> '' (perlbug@perl.org perl-win32-porters@perl.org modulebug@perl.org perlbug@perl.org macperlbug@perl.org)";
OK\, there's blank values there\, but where's the concatenation or is it one of these healthy (clear) implicit things?
You're kidding\, right?
Cheers\, Philip
Philip Newton wrote:
On Mon\, 3 Apr 2000\, Richard Foley wrote:
Trying to print out some debugging info with the following statement: print "targets($tgt) -> targets(@targets) -> '$dest' (@dest)";
Produces the following (IMHO strange) output: Use of uninitialized value in concatenation (.) at ..//Perlbug/Email.pm line 815
The actual string looks like this: targets() -> targets(unix win32 module generic macos) -> '' (perlbug@perl.org perl-win32-porters@perl.org modulebug@perl.org perlbug@perl.org macperlbug@perl.org)";
OK\, there's blank values there\, but where's the concatenation or is it one of these healthy (clear) implicit things?
You're kidding\, right? Nope\, try it another way:
my $str = "$this and @that"; # -> Use of uninitialized value in concatenation (.) at .. bla bla
There may indeed be concatenation going on in building the string\, but my question is more to do with whether I'm the only one who thinks the message is a bit misleading with the 'concatenation (.)' bit. I can't see a single period in the string: "$this and @that" and I'm not explicitly joining anything.
Woof
Ciao Richard Foley
richard@rfi.net 'Ciao' - shorter than 'Aufwiedersehen'
Philip Newton wrote:
On Mon\, 3 Apr 2000\, Richard Foley wrote:
Trying to print out some debugging info with the following statement: print "targets($tgt) -> targets(@targets) -> '$dest' (@dest)";
Produces the following (IMHO strange) output: Use of uninitialized value in concatenation (.) at ..//Perlbug/Email.pm line 815
The actual string looks like this: targets() -> targets(unix win32 module generic macos) -> '' (perlbug@perl.org perl-win32-porters@perl.org modulebug@perl.org perlbug@perl.org macperlbug@perl.org)";
OK\, there's blank values there\, but where's the concatenation or is it one of these healthy (clear) implicit things?
You're kidding\, right? Nope\, and nor are a few other\, I guess I should read the bug database... :-\
http://bugs.perl.org/perlbug.cgi?req=tidmids&tidmids=20000330.052
Ciao Richard Foley
richard@rfi.net 'Ciao' - shorter than 'Aufwiedersehen'
There may indeed be concatenation going on in building the string\, but my question is more to do with whether I'm the only one who thinks the message is a bit misleading with the 'concatenation (.)' bit. I can't see a single period in the string: "$this and @that" and I'm not explicitly joining anything.
On Tue\, 4 Apr 2000\, Richard Foley wrote:
Philip Newton wrote:
You're kidding\, right? Nope\, and nor are a few other\, I guess I should read the bug database... :-\
That's why I was asking -- this question has been making the rounds of p5p for the last week or so (or two weeks?)\, and it was explained why the warning produced is the way it is. Whether this is good or confusing depends on whom you ask.
Cheers\, Philip
Tom Christiansen wrote:
a bit misleading with the 'concatenation (.)' bit. I can't see a single period in the string: "$this and @that" and I'm not explicitly joining anything.
+# ifdef STUPID_LUSERS_FEAR_CORRECT_WARNINGS
Nothing like polite comments in the code to make us all feel at home with the clever people
:-)
Ciao Richard Foley
richard@rfi.net 'Ciao' - shorter than 'Aufwiedersehen'
+# ifdef STUPID_LUSERS_FEAR_CORRECT_WARNINGS
Nothing like polite comments in the code to make us all feel at home with the clever people :-)
Honesty is one of my vices.
--tom
Lightning flashed\, thunder crashed and Tom Christiansen \<tchrist@chthon.perl.co m> whispered: | >There may indeed be concatenation going on in building the string\, but my | >question is more to do with whether I'm the only one who thinks the message
is >a bit misleading with the 'concatenation (.)' bit. I can't see a single >period in the string: "$this and @that" and I'm not explicitly joining >anything. --- /usr/local/src/perls/perl-5.6.0/sv.c Thu Mar 23 14:44:37 2000 +++ ./sv.c Sat Apr 1 08:36:08 2000 @@ -218\,10 +218\,26 @@
How about the much less inflamatory\, and much more useful:
Which causes: ./perl -we ' print "$x and $y"' Name "main::x" used only once: possible typo at -e line 1. Name "main::y" used only once: possible typo at -e line 1. Use of uninitialized value in string or concatenation (.) at -e line 1. Use of uninitialized value in string or concatenation (.) at -e line 1.
-spp
How about the much less inflamatory\, and much more useful:
How about addressing the real issue?
% perl -lwe '@a[0\,2] = (0\,2); print "@a $a"\, "$a"\, $a' Use of uninitialized value in join at -e line 1. Use of uninitialized value in concatenation (.) at -e line 1. Use of uninitialized value in string at -e line 1. Use of uninitialized value in print at -e line 1.
Those are all different cases. They should not be conflated just to stick a pacifier in the mouths of the confused\, because that would penalize the rest of us. People are can't understand warnings should hire a programmer who can.
The real issue is ignorance. Solve it by education.
--tom
The opcodes that Perl compiles your program into ARE NOT THE ONES THAT YOU SAW.
There are a million cases of this. Here are two:
% perl -MO=Deparse -e 'for($i=0; $i\<10; $i++){}' $i = 0; while ($i \< 10) { (); } continue { ++$i }
Look\, there's NO for loop there anymore! My goodness\, what a terrible bug! What are you going to do now\, change that too? Also\, the postinc you wrote is NOT what Perl is going to execute. It's a different opcode. There are *plenty* of other cases like this. It's what the compiler is doing. Here's another:
% perl -MO=Deparse -ne '$seen{$_}++ && print'
LINE: while (defined($_ = \
I NEVER SAID if. But look at that! And where did that LINE label come from? I never said that either. Dang it\, perl is broken. What do you propose to do about these terrible errors\, huh?
--tom
Tom Christiansen wrote:
+# ifdef STUPID_LUSERS_FEAR_CORRECT_WARNINGS
Nothing like polite comments in the code to make us all feel at home with the clever people :-)
Honesty is one of my vices.
--tom
Shucks\, now you're just being coy.
Ciao Richard Foley
richard@rfi.net 'Ciao' - shorter than 'Aufwiedersehen'
Lightning flashed\, thunder crashed and Tom Christiansen \<tchrist@chthon.perl.co m> whispered: | The opcodes that Perl compiles your program into ARE NOT THE ONES | THAT YOU SAW. |
---|---|---|
There are a million cases of this. Here are two: |
There may be a million cases of this\, but there are not a million cases that are springing up repeatedly and confusing lots of people - even people who are part of the subcommunity that should know better. If one of those starts spewing error messages that confuse people\, then yes\, I will recommend and suggest patches that make the errors less confusing.
"The language is intended to be practical (easy to use\, efficient\, complete) rather than beautiful (tiny\, elegant\, minimal)."
Strangely\, all those examples that you provided compile without confusing error messages. Show me one example where changing "concatenation (.)" to "string or concatenation (.)" will be more confusing than it is now\, and I'll withdraw my patch. But only on the condition that you withdraw yours as well\, since it is obviously only meant to be inflamatory rather than trying to help the community.
-spp
error messages. Show me one example where changing "concatenation (.)" to "string or concatenation (.)" will be more confusing than it is now\, and I'll withdraw my patch.
Yours is lying. Mine isn't.
--tom
PERL IS BROKEN AGAIN!
use warnings; use Carp; $SIG{__WARN__} = \&Carp::cluck;
sub Funny::guy { my $whoami = (caller(0))[3]; print("$whoami: where is my $x?\n"); }
*snagglepuss = \&Funny::guy;
snagglepuss();
no warnings 'redefine'; *snagglepuss = sub { my $whoami = (caller(0))[3]; print("$whoami: where is my $x?\n"); };
snagglepuss();
Look at this:
Use of uninitialized value in concatenation (.) at /tmp/a line 7. Funny::guy() called at /tmp/a line 12 Use of uninitialized value in concatenation (.) at /tmp/a line 17. main::__ANON__() called at /tmp/a line 20 Funny::guy: where is my ? main::__ANON__: where is my ?
Where is snagglepuss? I called it twice! Perl is lying to me. Snivelling suckatush.
--tom
Strangely\, all those examples that you provided compile without confusing error messages.
So do those that blew away your brain.
% perl -cwe 'print "$x $x $x"' -e syntax OK
SEE ALSO The Perl Compiler The Perl Intepreter
--tom
On Tue\, 4 Apr 2000\, Tom Christiansen wrote:
The opcodes that Perl compiles your program into ARE NOT THE ONES THAT YOU SAW.
There are a million cases of this. Here are two:
% perl \-MO=Deparse \-e 'for\($i=0; $i\<10; $i\+\+\)\{\}' $i = 0; while \($i \< 10\) \{ \(\); \} continue \{ \+\+$i \}
This is an accurate description of what's going on on the perl side of things\, but isn't the average writer or reader of the code likely to be thinking in terms of 'for'?
Would a satisfactory approach be for the error message to be couched in terms of the source\, and perldiag/splain have the detail about the internal representation?
Mike
Would a satisfactory approach be for the error message to be couched in terms of the source\,
Perhaps\, except that we're talking interpreter warnings\, not compiler warnings. The compiler knows about three-part for loops; the interpreter does not. Likewise\, the compiler knows about string and array and slice interpolation; the interpreter does not.
--tom
At 08:11 AM 4/4/00 -0600\, Tom Christiansen wrote:
Would a satisfactory approach be for the error message to be couched in terms of the source\,
Perhaps\, except that we're talking interpreter warnings\, not compiler warnings. The compiler knows about three-part for loops; the interpreter does not. Likewise\, the compiler knows about string and array and slice interpolation; the interpreter does not.
Then we need to either:
A) Post in big bold letters someplace that internal optimizations may make the errors they get at runtime a little odd
or
B) Attach enough hint info to the optree to emit errors correct for the original program text
A's easier\, B's better but more expensive both in compile time and porter time. If the optimizer gets seriously attacked\, though\, it might be worth it.
Dan
--------------------------------------"it's like this"------------------- Dan Sugalski even samurai dan@sidhe.org have teddy bears and even teddy bears get drunk
Tom Christiansen wrote:
How about the much less inflamatory\, and much more useful:
How about addressing the real issue?
% perl -lwe '@a[0\,2] = (0\,2); print "@a $a"\, "$a"\, $a' Use of uninitialized value in join at -e line 1. Use of uninitialized value in concatenation (.) at -e line 1. Use of uninitialized value in string at -e line 1. Use of uninitialized value in print at -e line 1.
Those are all different cases. They should not be conflated just to stick a pacifier in the mouths of the confused\, because that It seems a shame to have to use another language\, just because a couple of warnings confuse once in a while.
would penalize the rest of us. People are can't understand warnings Why is a clear message a penalty?
should hire a programmer who can. It's apparently misleading enough to generate about seventy (occasionally off-topic) messages recently (most of which I have finally read).
The real issue is ignorance. Solve it by education. Finally\, unfortunately\, I have to agree with you on that one.
Ciao Richard Foley
richard@rfi.net 'Ciao' - shorter than 'Aufwiedersehen'
Those are all different cases. They should not be conflated just to stick a pacifier in the mouths of the confused\, because that It seems a shame to have to use another language\, just because a couple of warnings confuse once in a while.
Use the 1-Apr patch. No more confusion. Back to 5.005 days.
would penalize the rest of us. People are can't understand warnings Why is a clear message a penalty?
I keep asking the same question.
should hire a programmer who can. It's apparently misleading enough to generate about seventy (occasionally off-topic) messages recently (most of which I have finally read).
The real issue is ignorance. Solve it by education. Finally\, unfortunately\, I have to agree with you on that one.
Yup. Patches suggested.
--tom
Perhaps\, except that we're talking interpreter warnings\, not compiler warnings. The compiler knows about three-part for loops; the interpreter does not. Likewise\, the compiler knows about string and array and slice interpolation; the interpreter does not.
Then we need to either:
A) Post in big bold letters someplace that internal optimizations may make the errors they get at runtime a little odd
or
B) Attach enough hint info to the optree to emit errors correct for the original program text
A's easier\, B's better but more expensive both in compile time and porter time. If the optimizer gets seriously attacked\, though\, it might be worth it.
There are many many cases of this that could be "attacked". Essentially\, what people are suddenly expecting is that the compiler insert complete source code information during compilation so that during run time\, the interpreter can say things. Kind of like cc -g. This is potentially prohibitively expensive\, though\, as you point out. It's not like all cc compiles run with -g\, and for good reason.
Choice 1: Remove the warning and many others.
Choice 2: Educate the users. This is inevitable. Things just are not what they were. This is a compiler. That's what compilers do. Ever tried debugging highly optimized code from a DEC compiler? Whew!
Choice 3: Redesign the compiler and interpreter to store and access complete source code.
The bigger issue\, if you're going to be bloating the optree with full source information\, is to deal with
$x + $y
and not knowing which variable was wicked. It doesn't say
Undefined value in lexical $x defined at line 23 of Foo.pm Undefined value in global $Foo::y at line 23 of Foo.pm
--tom
From: Richard Foley [mailto:Richard.Foley@m.dasa.de] Tom Christiansen wrote:
How about the much less inflamatory\, and much more useful:
How about addressing the real issue?
% perl -lwe '@a[0\,2] = (0\,2); print "@a $a"\, "$a"\, $a' Use of uninitialized value in join at -e line 1. Use of uninitialized value in concatenation (.) at -e line 1. Use of uninitialized value in string at -e line 1. Use of uninitialized value in print at -e line 1.
Those are all different cases. They should not be conflated just to stick a pacifier in the mouths of the confused\, because that It seems a shame to have to use another language\, just because a couple of warnings confuse once in a while.
Why so many people are confusing? If one have brain then such warnings may be understood clearly. If that warning is misleading\, why other compiler's warnings are easily understood?
Look:
a.c #include \<stdio.h> typedef int my_type; void main () { my_type a; printf(a); }
MSVC++: d:\TESTS\x>cl a.c Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8168 for 80x86 Copyright (C) Microsoft Corp 1984-1998. All rights reserved.
a.c a.c(5) : warning C4047: 'function' : 'const char *' differs in levels of indirection from 'int ' a.c(5) : warning C4024: 'printf' : different types for formal and actual parameter 1 a.c(5) : warning C4700: local variable 'a' used without having been initialized Microsoft (R) Incremental Linker Version 6.00.8447 Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
/out:a.exe a.obj
BROKEN: a is 'my_type'\, not 'int '
GCC: d:\TESTS\x>gcc a.c a.c: In function `main': a.c:5: warning: passing arg 1 of `printf' makes pointer from integer without a cast a.c:3: warning: return type of `main' is not `int'
BROKEN: a is 'my_type'\, not integer
Yes\, Tom\, we all understand that there are many cases where different Perl syntax is compiled to identical opcodes\, and that the interpreter warnings reflect the compiled opcodes and not the original code.
But\, neither the compiler nor the interpreter is going to fix the Perl code that caused those warnings. That can only be done by the programmer\, and the warning messages should be optimized for the programmer\, not for the compiler or the interpreter.
Ronald
On Tue\, Apr 04\, 2000 at 06:45:31PM +0400\, Konovalov\, Vadim wrote:
Why so many people are confusing? If one have brain then such warnings may be understood clearly. If that warning is misleading\, why other compiler's warnings are easily understood?
Look:
a.c #include \<stdio.h> typedef int my_type; void main () { my_type a; printf(a); }
MSVC++: d:\TESTS\x>cl a.c Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8168 for 80x86 Copyright (C) Microsoft Corp 1984-1998. All rights reserved.
a.c a.c(5) : warning C4047: 'function' : 'const char *' differs in levels of indirection from 'int ' a.c(5) : warning C4024: 'printf' : different types for formal and actual parameter 1 a.c(5) : warning C4700: local variable 'a' used without having been initialized Microsoft (R) Incremental Linker Version 6.00.8447 Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
/out:a.exe a.obj
BROKEN: a is 'my_type'\, not 'int '
The C programmer here has explicitly defined my_type to be the same as int. If the programmer becomes confused\, it is his own fault.
On the other hand\, the Perl programmer has not explicitly defined string interpolation to be the same as string concatenation. That is an implementation detail of the Perl compiler. The programmer should not be required to know the internals of the compiler.
Ronald
Ronald J Kimball (lists.p5p):
Yes\, Tom\, we all understand that there are many cases where different Perl syntax is compiled to identical opcodes\, and that the interpreter warnings reflect the compiled opcodes and not the original code. But\, neither the compiler nor the interpreter is going to fix the Perl code that caused those warnings. That can only be done by the programmer\, and the warning messages should be optimized for the programmer\, not for the compiler or the interpreter.
What are you going to do about this?
othersideofthe:simon ~ % perl -we 'my $a; my $b="one"; print $a\, $b' Use of uninitialized value in print at -e line 1.
If you're optimising for the programmer\, you tell him which variable it is.
Patch welcome.
On Tue\, Apr 04\, 2000 at 02:51:12PM +0000\, Simon Cozens wrote:
Ronald J Kimball (lists.p5p):
Yes\, Tom\, we all understand that there are many cases where different Perl syntax is compiled to identical opcodes\, and that the interpreter warnings reflect the compiled opcodes and not the original code. But\, neither the compiler nor the interpreter is going to fix the Perl code that caused those warnings. That can only be done by the programmer\, and the warning messages should be optimized for the programmer\, not for the compiler or the interpreter.
What are you going to do about this?
I recommend changing the opcode descriptions from 'concatenation (.)' and 'join' to 'concatenation (.) or string' and 'join or string'.
othersideofthe:simon ~ % perl -we 'my $a; my $b="one"; print $a\, $b' Use of uninitialized value in print at -e line 1.
If you're optimising for the programmer\, you tell him which variable it is.
Solving this problem would probably be judged too expensive and I doubt a patch for it would be approved.
Ronald
On the other hand\, the Perl programmer has not explicitly defined string interpolation to be the same as string concatenation.
That's right: the user has not--the language has.
That is an implementation detail of the Perl compiler. The programmer should not be required to know the internals of the compiler.
"String interpolation is a form of concatenation." I'm sure it says that somewhere.
--tom
On Tue\, Apr 04\, 2000 at 08:59:46AM -0600\, Tom Christiansen wrote:
On the other hand\, the Perl programmer has not explicitly defined string interpolation to be the same as string concatenation.
That's right: the user has not--the language has.
That is an implementation detail of the Perl compiler. The programmer should not be required to know the internals of the compiler.
"String interpolation is a form of concatenation." I'm sure it says that somewhere.
I'm not sure it does... I looked through perlop and grepped all the pod for 'interpo' and 'concat' on the same or adjacent lines\, but didn't find that.
Anyway\, why shouldn't it say that in the warning message as well? If we want to educate people that string interpolation is the same as concatenation\, that seems like a good place to do it.
Ronald
BROKEN: a is 'my_type'\, not 'int '
The C programmer here has explicitly defined my_type to be the same as int. If the programmer becomes confused\, it is his own fault.
On the other hand\, the Perl programmer has not explicitly defined string interpolation to be the same as string concatenation. That is an implementation detail of the Perl compiler. The programmer should not be required to know the internals of the compiler.
wchar_t in MSVC++ is typedef'd somewhere in it's internal headers and programmer not only does not care it's real type\, but he(she) should not rely on it's real type\, because it may change. But compiler gives warnings about "unsigned short int" (AFAIR). Here are internals of compiler.
I think many more examples may be given\, example about typedef just came to me because I saw it today...
Good luck\, Vadim.
my(%h\, $x\, $y\, $z); %h = ($x => $y . $z); Use of uninitialized value in concatenation (.) at - line 2. Use of uninitialized value in concatenation (.) at - line 2. Use of uninitialized value in list assignment at - line 2.
No\, I was assigning a hash.
my(%h\, %g\, $x\, $y\, $z); %h = ($x => $y . $z); %g = %h; Use of uninitialized value in concatenation (.) at - line 3. Use of uninitialized value in concatenation (.) at - line 3. Use of uninitialized value in list assignment at - line 3.
There was no list on either side. Those are just hashes. It's an "accident of the compiler's implementation" that this turns into a list. It could detect this and do something else.
my(%h\, %g\, $x\, $y\, $z); %h = ("$x" => $y . $z); %g = %h; Use of uninitialized value in string at - line 2. Use of uninitialized value in concatenation (.) at - line 2. Use of uninitialized value in concatenation (.) at - line 2.
List assignment? What list assigment? This must be wrong.
my(@a\, $x\, $y\, $z); @a = ($x\, $y . $z); Use of uninitialized value in concatenation (.) at - line 2. Use of uninitialized value in concatenation (.) at - line 2.
Huh? Why didn't this complaint? It's a list assignment! Isn't it?
my(@a\, $x\, $y\, $z); @a = ("$x"\, "$y$z"); Use of uninitialized value in string at - line 2. Use of uninitialized value in concatenation (.) at - line 2. Use of uninitialized value in concatenation (.) at - line 2.
my(@a\, %h\, $x\, $y\, $z); @a = ($x => $x\, "$x"\, "$y$z"\, undef() => $x.$y.$z); %h = ($x => "@a"\, @a => @a\, $y => join($x\,$y\,$z)\, @a); Use of uninitialized value in string at - line 2. Use of uninitialized value in concatenation (.) at - line 2. Use of uninitialized value in concatenation (.) at - line 2. Use of uninitialized value in concatenation (.) at - line 2. Use of uninitialized value in concatenation (.) at - line 2. Use of uninitialized value in concatenation (.) at - line 2. Use of uninitialized value in join at - line 3. Use of uninitialized value in join at - line 3. Use of uninitialized value in join at - line 3. Use of uninitialized value in join at - line 3. Use of uninitialized value in join at - line 3. Use of uninitialized value in join at - line 3. Use of uninitialized value in list assignment at - line 3. Use of uninitialized value in list assignment at - line 3. Use of uninitialized value in list assignment at - line 3. Use of uninitialized value in list assignment at - line 3. Use of uninitialized value in list assignment at - line 3. Use of uninitialized value in list assignment at - line 3. Use of uninitialized value in list assignment at - line 3. Use of uninitialized value in list assignment at - line 3.
I ask you seriously: what it the *OPTIMAL* text you want to see here? Let's pretend nothing is impossible. What do you REALLY want?
--tom
At 08:39 AM 4/4/00 -0600\, Tom Christiansen wrote:
Perhaps\, except that we're talking interpreter warnings\, not compiler warnings. The compiler knows about three-part for loops; the interpreter does not. Likewise\, the compiler knows about string and array and slice interpolation; the interpreter does not.
Then we need to either:
A) Post in big bold letters someplace that internal optimizations may make the errors they get at runtime a little odd
or
B) Attach enough hint info to the optree to emit errors correct for the original program text
A's easier\, B's better but more expensive both in compile time and porter time. If the optimizer gets seriously attacked\, though\, it might be worth it.
There are many many cases of this that could be "attacked". Essentially\, what people are suddenly expecting is that the compiler insert complete source code information during compilation so that during run time\, the interpreter can say things. Kind of like cc -g. This is potentially prohibitively expensive\, though\, as you point out. It's not like all cc compiles run with -g\, and for good reason.
True\, but there's no reason (well\, no reason short of a profound lack of time) that we can't add a -g-ish option to perl to do just that. (Makes me really want to be able to bytecode compile modules\, too)
Choice 1: Remove the warning and many others.
Ick. But that goes without saying.
Choice 2: Educate the users. This is inevitable. Things just are not what they were. This is a compiler. That's what compilers do.
True\, but this is also perl\, which does its best to make things easy for its users. (Besides\, I've been tech support and a sysadmin--I've what most people'd call an amazingly cynical view of humanity\, except it's depressingly rarely wrong...)
Ever tried debugging highly optimized code from a DEC compiler? Whew!
Why\, yes! Often. :)
If you think the output from Dec C in heavy-optimize mode's bad\, try debugging the output of the Fortran compiler. Not doing pointers lets the compiler do some breathtaking optimizations.
Choice 3: Redesign the compiler and interpreter to store and access complete source code.
Full source isn't needed. For some things less is required\, and for others probably more.
The bigger issue\, if you're going to be bloating the optree with full source information\, is to deal with
$x \+ $y
and not knowing which variable was wicked. It doesn't say
Undefined value in lexical $x defined at line 23 of Foo\.pm Undefined value in global $Foo​::y at line 23 of Foo\.pm
If we're storing enough data to give partially meaningful messages then yes\, we should provide some way to ferret out the name of the variable in these cases.
Dan
--------------------------------------"it's like this"------------------- Dan Sugalski even samurai dan@sidhe.org have teddy bears and even teddy bears get drunk
"String interpolation is a form of concatenation." I'm sure it says that somewhere.
I'm not sure it does... I looked through perlop and grepped all the pod for 'interpo' and 'concat' on the same or adjacent lines\, but didn't find that.
Found it. Blue Camel\, rendered into pod for simple reading:
Note that Perl I\
$fullname = "$firstname $lastname";
Anyway\, why shouldn't it say that in the warning message as well? If we want to educate people that string interpolation is the same as concatenation\, that seems like a good place to do it.
Perhaps somewhere one could say something like this:
This means that you can insert the values of certain variables directly into a string literal. It's really just a handy form of string concatenation. (With warning enabled\, Perl reports undefined values interpolated into strings as using the concatenation or join operations. Even though you don't actually see those operators there. The compiler created them for you anyway.)
--tom
PS: I note that the whiners haven't tackled the problem of line numbers and interpolation into HERE docs.
Undefined value in lexical $x defined at line 23 of Foo\.pm Undefined value in global $Foo​::y at line 23 of Foo\.pm
If we're storing enough data to give partially meaningful messages then yes\, we should provide some way to ferret out the name of the variable in these cases.
Oops\, I meant more like this:
Undefined value in lexical $x first defined at line 14 of Foo.pm used at line 23 of Foo.pm Undefined value in global $Foo::y at line 23 of Foo.pm
That is\, you must name a lexical according to where it is first defined\, but a global according to its package.
--tom
At 09:29 AM 4/4/00 -0600\, Tom Christiansen wrote:
Undefined value in lexical $x defined at line 23 of Foo\.pm Undefined value in global $Foo​::y at line 23 of Foo\.pm
If we're storing enough data to give partially meaningful messages then yes\, we should provide some way to ferret out the name of the variable in these cases.
Oops\, I meant more like this:
Undefined value in lexical $x first defined at line 14 of Foo\.pm used at line 23 of Foo\.pm Undefined value in global $Foo​::y at line 23 of Foo\.pm
That is\, you must name a lexical according to where it is first defined\, but a global according to its package.
Sure--should we add in the recursion level too while we're at it?
Dan
--------------------------------------"it's like this"------------------- Dan Sugalski even samurai dan@sidhe.org have teddy bears and even teddy bears get drunk
On Tue\, Apr 04\, 2000 at 09:22:08AM -0600\, Tom Christiansen wrote:
my(%h\, %g\, $x\, $y\, $z); %h = ($x => $y . $z); %g = %h; Use of uninitialized value in concatenation (.) at - line 3. Use of uninitialized value in concatenation (.) at - line 3. Use of uninitialized value in list assignment at - line 3.
There was no list on either side. Those are just hashes. It's an "accident of the compiler's implementation" that this turns into a list. It could detect this and do something else.
Running that code produces warnings for line 2\, not line 3.
my(@a\, %h\, $x\, $y\, $z); @a = ($x => $x\, "$x"\, "$y$z"\, undef() => $x.$y.$z); %h = ($x => "@a"\, @a => @a\, $y => join($x\,$y\,$z)\, @a); Use of uninitialized value in string at - line 2. Use of uninitialized value in concatenation (.) at - line 2. Use of uninitialized value in concatenation (.) at - line 2. Use of uninitialized value in concatenation (.) at - line 2. Use of uninitialized value in concatenation (.) at - line 2. Use of uninitialized value in concatenation (.) at - line 2. Use of uninitialized value in join at - line 3. Use of uninitialized value in join at - line 3. Use of uninitialized value in join at - line 3. Use of uninitialized value in join at - line 3. Use of uninitialized value in join at - line 3. Use of uninitialized value in join at - line 3. Use of uninitialized value in list assignment at - line 3. Use of uninitialized value in list assignment at - line 3. Use of uninitialized value in list assignment at - line 3. Use of uninitialized value in list assignment at - line 3. Use of uninitialized value in list assignment at - line 3. Use of uninitialized value in list assignment at - line 3. Use of uninitialized value in list assignment at - line 3. Use of uninitialized value in list assignment at - line 3.
I ask you seriously: what it the *OPTIMAL* text you want to see here? Let's pretend nothing is impossible. What do you REALLY want?
If nothing were impossible\, I think something like this would be optimal:
Value of lexical $x is undefined in string at - line 2. Value of lexical $y is undefined in string at - line 2. Value of lexical $z is undefined in string at - line 2. Value of lexical $x is undefined in concatenation (.) at - line 2. Value of lexical $y is undefined in concatenation (.) at - line 2. Value of lexical $z is undefined in concatenation (.) at - line 2. Value of element 0 of lexical @a is undefined in string at - line 3. Value of element 1 of lexical @a is undefined in string at - line 3. Value of element 4 of lexical @a is undefined in string at - line 3. Value of lexical $x is undefined in join at - line 3. Value of lexical $y is undefined in join at - line 3. Value of lexical $z is undefined in join at - line 3. Value of lexical $x is undefined in hash assignment at - line 3. Value of element 0 of lexical @a is undefined in hash assignment at - line 3. Value of element 4 of lexical @a is undefined in hash assignment at - line 3. Value of element 0 of lexical @a is undefined in hash assignment at - line 3. Value of element 4 of lexical @a is undefined in hash assignment at - line 3. Value of lexical $y is undefined in hash assignment at - line 3. Value of element 0 of lexical @a is undefined in hash assignment at - line 3. Value of element 4 of lexical @a is undefined in hash assignment at - line 3.
In a case such as C\<undef() . "">\, I would do:
Value is undefined in concatenation ...
or something like that.
The perldiag entry would be:
Value%s is undefined in %s
Ronald
On Tue\, Apr 04\, 2000 at 12:03:29PM -0400\, Ronald J Kimball wrote:
On Tue\, Apr 04\, 2000 at 09:22:08AM -0600\, Tom Christiansen wrote:
my(%h\, %g\, $x\, $y\, $z); %h = ($x => $y . $z); %g = %h; Use of uninitialized value in concatenation (.) at - line 3. Use of uninitialized value in concatenation (.) at - line 3. Use of uninitialized value in list assignment at - line 3.
There was no list on either side. Those are just hashes. It's an "accident of the compiler's implementation" that this turns into a list. It could detect this and do something else.
Running that code produces warnings for line 2\, not line 3.
my(@a\, %h\, $x\, $y\, $z); @a = ($x => $x\, "$x"\, "$y$z"\, undef() => $x.$y.$z); %h = ($x => "@a"\, @a => @a\, $y => join($x\,$y\,$z)\, @a); Use of uninitialized value in string at - line 2. Use of uninitialized value in concatenation (.) at - line 2. Use of uninitialized value in concatenation (.) at - line 2. Use of uninitialized value in concatenation (.) at - line 2. Use of uninitialized value in concatenation (.) at - line 2. Use of uninitialized value in concatenation (.) at - line 2. Use of uninitialized value in join at - line 3. Use of uninitialized value in join at - line 3. Use of uninitialized value in join at - line 3. Use of uninitialized value in join at - line 3. Use of uninitialized value in join at - line 3. Use of uninitialized value in join at - line 3. Use of uninitialized value in list assignment at - line 3. Use of uninitialized value in list assignment at - line 3. Use of uninitialized value in list assignment at - line 3. Use of uninitialized value in list assignment at - line 3. Use of uninitialized value in list assignment at - line 3. Use of uninitialized value in list assignment at - line 3. Use of uninitialized value in list assignment at - line 3. Use of uninitialized value in list assignment at - line 3.
I ask you seriously: what it the *OPTIMAL* text you want to see here? Let's pretend nothing is impossible. What do you REALLY want?
If nothing were impossible\, I think something like this would be optimal:
Value of lexical $x is undefined in string at - line 2. Value of lexical $y is undefined in string at - line 2. Value of lexical $z is undefined in string at - line 2. Value of lexical $x is undefined in concatenation (.) at - line 2. Value of lexical $y is undefined in concatenation (.) at - line 2. Value of lexical $z is undefined in concatenation (.) at - line 2. Value of element 0 of lexical @a is undefined in string at - line 3. Value of element 1 of lexical @a is undefined in string at - line 3. Value of element 4 of lexical @a is undefined in string at - line 3. Value of lexical $x is undefined in join at - line 3. Value of lexical $y is undefined in join at - line 3. Value of lexical $z is undefined in join at - line 3. Value of lexical $x is undefined in hash assignment at - line 3. Value of element 0 of lexical @a is undefined in hash assignment at - line 3. Value of element 4 of lexical @a is undefined in hash assignment at - line 3. Value of element 0 of lexical @a is undefined in hash assignment at - line 3. Value of element 4 of lexical @a is undefined in hash assignment at - line 3. Value of lexical $y is undefined in hash assignment at - line 3. Value of element 0 of lexical @a is undefined in hash assignment at - line 3. Value of element 4 of lexical @a is undefined in hash assignment at - line 3.
In a case such as C\<undef() . "">\, I would do:
Value is undefined in concatenation ...
or something like that.
Actually\, make that:
Value of undef() is undefined in concatenation ...
It's a bit silly\, but more explicit.
The perldiag entry would be:
Value%s is undefined in %s
And that would become:
Value of %s is undefined in %s
Ronald
"Stephen P. Potter" \spp@​spp\.users\.ds\.net wrote
How about the much less inflamatory\, and much more useful:
--- opcode.h~ Tue Apr 4 09:30:06 2000 +++ opcode.h Tue Apr 4 09:26:38 2000
Not as useful as it might be - see the top of opcode.h: :-)
/* !!!!!!! DO NOT EDIT THIS FILE !!!!!!! This file is built by opcode.pl from its data. Any changes made here will be lost! */
And the tests need fixing. Here's a second attempt.
Mike Guy
To: perl5-porters@perl.org From: Zenin \zenin@​bawdycaste\.org Subject: Re: [ID 20000403.009] uninitialised concatenation??? X-Newsgroups: perl.porters-gw In-Reply-To: \4\.3\.0\.20000404101328\.018e1d30@​24\.8\.96\.48 \2104\.954859198@​chthon Organization: Zenin's Rocky Horror Archive User-Agent: tin/pre-1.4-19990413 ("Endemoniada") (UNIX) (FreeBSD/3.2-STABLE (i386))
In message \2104\.954859198@​chthon Tom Christiansen \tchrist@​chthon\.perl\.com wrote: >snip\< :>Then we need to either: :>A) Post in big bold letters someplace that internal optimizations may make :>the errors they get at runtime a little odd :>or :>B) Attach enough hint info to the optree to emit errors correct for the :>original program text :>A's easier\, B's better but more expensive both in compile time and porter :>time. If the optimizer gets seriously attacked\, though\, it might be worth it. : : There are many many cases of this that could be "attacked". Essentially\, : what people are suddenly expecting is that the compiler insert complete : source code information during compilation so that during run time\, the : interpreter can say things. Kind of like cc -g. This is potentially : prohibitively expensive\, though\, as you point out. It's not like all cc : compiles run with -g\, and for good reason.
How about adding a -g option to perl to do just that?
: Choice 1: Remove the warning and many others.
I'd prefer not to remove it myself. It's rare except in small programs that I've used uninitialized values where it wasn't an indication of a bug in my code someplace.
: Choice 2: Educate the users. This is inevitable. Things just are not : what they were. This is a compiler. That's what compilers do. Ever : tried debugging highly optimized code from a DEC compiler? Whew!
Agreed. Every compiler has its quirks. Hell\, javac even has a page (part of the FAQ?) that details nearly every error message and what it *really* means. Perhaps perl needs something similar?
: Choice 3: Redesign the compiler and interpreter to store and access : complete source code. : : The bigger issue\, if you're going to be bloating the optree with full : source information\, is to deal with : $x + $y : and not knowing which variable was wicked. It doesn't say : Undefined value in lexical $x defined at line 23 of Foo.pm : Undefined value in global $Foo::y at line 23 of Foo.pm
Which would be nice\, at least via a switch (-g or something). Probably too much work for the result however. I'd prefer to see threads happier then warning messages\, for instance.
Does this make anybody happy?
(Also\, it may be relevant to mention that B::Deparse gives different results for 'print " " . $a' and 'print " $a"'\, but I'm probably missing something. Also\, exploration of this came up with another uninitialized value problem in B::Deparse\, but I'm too lazy to look at it now.)
Byron Bummer wrote:
Agreed. Every compiler has its quirks. Hell\, javac even has a page (part of the FAQ?) that details nearly every error message and what it *really* means. Perhaps perl needs something similar?
You mean like perldiag.pod/use diagnostics?
--David Glasser
glasser@iname.com
David Glasser \dglasser@​mail\.your\-site\.com wrote:
Byron Bummer wrote:
Agreed. Every compiler has its quirks. Hell\, javac even has a page (part of the FAQ?) that details nearly every error message and what it *really* means. Perhaps perl needs something similar?
You mean like perldiag.pod/use diagnostics?
Not quite what I had in mind. Perldiag is good\, but it fails to properly decode many messages. It describes what the message means\, but not quite as often how you got there\, which is context dependent.
The concatenation message is one such example\, but there are many others. Granted though\, most examples I've found are syntax error messages and not runtime warnings. Still\, given the existence of eval("") these could be the same\, for all usefulness.
Granted though\, most examples I've found are syntax error messages and not runtime warnings.
So? The pragma helps both.
% perl -Mstrict -Mdiagnostics
$x = 1;
Global symbol "$x" requires explicit package name at - line 1 (#1)
(F) You've said "use strict vars"\, which indicates that all variables
must either be lexically scoped (using "my")\, declared beforehand using
"our"\, or explicitly qualified to say which package the global variable
is in (using "::").
$x += $x + /;
Global symbol "$x" requires explicit package name at - line 2 (#1)
^D
Search pattern not terminated at - line 2 (#2)
(F) The lexer couldn't find the final delimiter of a // or m{}
construct. Remember that bracketing delimiters count nesting level.
Missing the leading $ from a variable $m may cause this error.
Uncaught exception from user code:
Search pattern not terminated at - line 2.
Exit 255
--tom
David Glasser (lists.p5p):
Does this make anybody happy?
A few (minor) changes would make me very happy indeed. In the spirit of not exposing the internals to the ordinary user\, I think we may want to avoid talking about opcodes. Also\, the error message is displayed by perl\, not by the program! :)
David Glasser (lists.p5p):
Does this make anybody happy?
A few (minor) changes would make me very happy indeed. In the spirit of not exposing the internals to the ordinary user\, I think we may want to avoid talking about opcodes. Also\, the error message is displayed by perl\, not by the program! :)
Those are good changes\, but do you really want to split "that " over a line break?
(I should make a new patch but I'm too lazy to boot into linux. One of these days I'll start doing email over there.)
+in your program. For example\, C\<"that $foo"> is usually optimized into C\<"that +" . $foo>\, and the warning will refer to the C\<concatenation (.)> operator\,
--David
glasser@iname.com
Body was too large for import. Click here for the attachment in RT
simon@brecon.co.uk (Simon Cozens) wrote
Grief\, this message is already messy enough in a standard 80-column wide terminal. This patch makes things nicer for those of us still on glass TTYs:
You obviously misswed my bug report [ID 20000401.009]\, found in
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-04/msg00052.html
in which this layout is corrected\, and a couple of other bugs are mended.
Note also that because "use diagnostics" offsets the message\, lines in perldiag.pod should be limited to 76 characters\, and preferably to 72.
Mike Guy
M.J.T. Guy (lists.p5p):
You obviously misswed my bug report [ID 20000401.009]\, found in http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-04/msg00052.html in which this layout is corrected\, and a couple of other bugs are mended.
I did indeed.
Note also that because "use diagnostics" offsets the message\, lines in perldiag.pod should be limited to 76 characters\, and preferably to 72.
Well\, that's what that patch was attempting to do. I'll apply that\, then write the new blurb on unitialised thingies.
Well\, that's what that patch was attempting to do. I'll apply that\, then write the new blurb on unitialised thingies.
There are no "unitialised thingies". There are merely scalar values which are undef. One must banish the notion of definedness from one's mind when contemplating aggregates\, for definedness is a singular notion impertinent to arrays and hashes.
--tom
Tom Christiansen (lists.p5p):
Well\, that's what that patch was attempting to do. I'll apply that\, then write the new blurb on unitialised thingies.
There are no "unitialised thingies". There are merely scalar values which are undef. One must banish the notion of definedness from one's mind when contemplating aggregates
You think I was attempting to be coherent when I sent that mail?
Migrated from rt.perl.org#2992 (status was 'resolved')
Searchable as RT2992$