develooper Front page | perl.perl5.porters | Postings from March 2000

Re: [ID 20000330.052] Use of uninitialized value in concatenation (.)

Thread Previous | Thread Next
From:
Tom Christiansen
Date:
March 31, 2000 07:23
Subject:
Re: [ID 20000330.052] Use of uninitialized value in concatenation (.)
Message ID:
28709.954516179@chthon
>Tom, saying that just because an underlying implementation detail is
>accurate, doesn't make it accurate in this case.  Think about if I brought
>you a car and the windshield wipers didn't work.  If I told you "I think
>there's something wrong with the wiper motor" would you argue "actually, it
>isn't the motor that is the problem, it is the electromagnets inside the
>motor that aren't working correctly."

Yeah whatever, Mr Smarty Pants.  I don't see any patches about this
issuing from *your* neck of the woods.  Perhaps you should just go
back to your non-reading status, since with that would come also
non-whining.  Until you have a concrete suggestion about precisely
how to go about "fixing" this non-bug particularly in light of the
related matters you're ignoring, you're just pissing in the wind.

SUMMARY: Less pissing, more patching!

For years people whined about not knowing what operators were causing
that warning.  Now that they're actually being told, they whine
about not being smart enough to understand what an operator *is*.
Talk about punching a gift horse in the mouth!  You get something
valuable you didn't have before, and all you can do it complain.
Well, you don't deserve it then, now do you?  Kindly examine opcode.h
and explain which kind of opcode you expect us to be using here.
Hint: it's not pp_stringify.

The simple fact is that string "interpolation" is just syntactic
sugar for catenation.  This happens in more places than you're even
thinking about right now.  It's too bad if you're unwilling or
unable to understand that, but that's just your tough luck, now
isn't it?

Shall we break the following just to pacify the ignorant?

% cat /tmp/a
print <<EOF, qq'what $x is that?', 
This here little
expansion of 
the bogus
var $x that we have 
sure is fun, isn't it?
EOF
qx{
    echo 'And tell me, how do 
	  you feel about this $x, 
	  eh there?'
}, $,,
qx'echo "oh boy, here is 
$x all over again"', 
$y . $x . $y;

Notice all those catenative constructs!

% perl -w /tmp/a
Use of uninitialized value in concatenation (.) at /tmp/a line 1.
Use of uninitialized value in concatenation (.) at /tmp/a line 1.
Use of uninitialized value in concatenation (.) at /tmp/a line 1.
Use of uninitialized value in concatenation (.) at /tmp/a line 1.
Use of uninitialized value in concatenation (.) at /tmp/a line 1.
Use of uninitialized value in concatenation (.) at /tmp/a line 1.
Use of uninitialized value in print at /tmp/a line 1.
This here little
expansion of 
the bogus
var  that we have 
sure is fun, isn't it?
what  is that?And tell me, how do 
	  you feel about this , 
	  eh there?
oh boy, here is 
 all over again

As you can plainly see, the interpreter is faithfully and honestly
reporting the condition of the code the compiler handed it:

% perl -MO=Deparse,-q /tmp/a
print "This here little\nexpansion of \nthe bogus\nvar " . $x . " that we have \nsure is fun, isn't it?\n", 'what ' . $x . ' is that?', `\n    echo 'And tell me, how do \n\t  you feel about this $x, \n\t  eh there?'\n`, $,, `echo "oh boy, here is \n\$x all over again"`, $y . $x . $y;

I suppose you expect `` to say one thing and qx() another thing,
too?  And of course, those silly heredocs better tell you just what
they are -- none of this concat business.  Tell me, what's the
herdoc opcode?  When you write it, make sure that they also say
what the problem was and where within the string it occurred, their
ending strings, their real line numbers, everything.  I do hope you
intend that that be "fixed" as well.

The solution is simple: Go for it, Stephen!  Go create us a bunch
of spurious opcode types in you interpreter redesign.  While you're
at it, don't forget to fix the line numbers, since of course that
little problem with print didn't occur at line 1, but further on
in the middle of various here docs (that don't even confess to their
nature or terminating strings!), which I expect to see you fix to
say where in the source code these occurred.  Make sure you can
tell the difference between a symbolically specified "\n" and a
literal linefeed, too, since one ought to add a line number and the
other oughtn't.  You get to figure out which is which.  Oh, and do
please fix the stunning lack of variable names.  What cheek!  I
fully expect perl to tell me the name of the variable that went
awry.

Or, perhaps, especially since I don't see you "fixing" a million
other things pilot brain damage effects--let alone this one--maybe
just maybe you might possibly instead consider trying to educate
away this ignorance rather than locking it in.  Offer up your patch
to perldiag and perltrap, and probably to other places, too.  If
you must be squeaky wheel, then you should be greasing your own
squeaks.

But maybe I'm wrong.  Maybe it *is* better that programmers not be
told about any of this at all, since that would be a lot easier
than actually doing what we can to keep them honestly informed.
Instead of teaching how any sort of string expansion--irrespective
of any syntactic sugar such as heredocs or the various denotations
for dq-strings or backticks--is really a compile-time catena of
individual operations, we could if you insist instead go back to
what many consider the bad old days of making them guess the operator.
Or we could go back even further to the dark ages when the compiler
didn't actually compile interpolation at compile time and make it
an idiotically redundant and gratuitously error-prone run-time
operation again.

Where's your plan, Stephen?  Patches speak louder than words.  Offer
up your patch, you or any others who about this might squeak, and
let then that patch be duly judged.

SUMMARY: Less squeaking, more patching!

--tom

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About