Re: RFC 214 (v1) Emit warnings and errors based on unoptimized code

[Steve Fink]

How much optimization are we talking about?

Currently, toke.c turns "foo$bar" into "foo".$bar before the parser or
anything else sees it. So any features implemented in the tokenizer have
to get smarter about remembering what they did.

If you do common subexpression elimination, one opcode may correspond to
multiple lines in the original source code.

If you re-order arguments to commutative operators, your lines get
really tangled up.

Consider
undef $y;
$x = 3
+
$y
+
4
;

You'd like to do $x=3+$y+4 -->(reorder) $x=(3+4)+$y -->(constant fold)
$x=7+$y. The warning is triggered by addition, but which one?

If you create an opcode during optimization, what line number do you
give it?

I suspect perl can do a much better job than it does now, but if you
make it a requirement, you prevent many optimizations. I think the RFC
should be very specific about when it applies and when it gets out of
the way.