At 10:27 PM 9/14/00 -0400, Chaim Frenkel wrote:
> >>>>> "SF" == Steve Fink <[EMAIL PROTECTED]> writes:
>
>SF> I suspect perl can do a much better job than it does now, but if you
>SF> make it a requirement, you prevent many optimizations. I think the RFC
>SF> should be very specific about when it applies and when it gets out of
>SF> the way.
>
>Expression movement should be attributable to the original line.
>Movement of multiple expressions from multiple to the same opcode,
>a small slippage should be acceptable.
Heh. We can change the message from:
"Division by zero error on line xx"
to
"Division by zero error somewhere around line XX, give or take a few"
:)
>But common expression where multiple lines end up at the same point
>loses information. But keeping one of the original line numbers
>would at least point at the correct expression.
Yup. Worst case we can always point at where the line starts, if it still
exists.
>The only movements that I can see are merges and reorgs. And we
>can generate a reasonable association to get the users eyeball
>to where it belongs.
I can't see anything more aggressive than that, but it's certainly
possible, and I'd like to not rule it out. Steve's right, we could be
really killing the possibility of funky optimization by forbidding it.
I think maybe we should integrate it in with the optimization level, which
is something I'd also like to deal with. Some optimizations are gonna be
costly, and really unneeded for one-off or short-running programs.
Once we've got a better handle on the byteode/optree stuff (or whatever we
do) I think we'll need to hand this off to a -internals-debug-optimize sublist.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
