Front page | perl.perl5.porters |
Postings from April 2000
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