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

Re: [ID 20000403.009] uninitialised concatenation???

From:
Dan Sugalski
Date:
April 4, 2000 08:25
Subject:
Re: [ID 20000403.009] uninitialised concatenation???
Message ID:
4.3.0.20000404111149.018f76b0@24.8.96.48
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




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