It seems to me that everyone in this thread pretty much agrees that this
is a good idea, but has one of the following reservations:
1) Tracking sufficient information to be able to report errors at the
exact spot they happen involves bloating the optree a lot and slowing down
the whole program;
2) The implementation of this idea is decidedly non-trivial.
First of all, does anyone have a concern other than these two?
As to solving #2...well, I'm going to wave my hands a lot and say,
"Oh, that's an SEP and besides, it's just a SMOP." Which, I realize, is
incredibly unfair.
As to solving problem #1 (which is, arguably, the bigger problem),
suppose we add a new switch to perl? I propose we add the -H switch
(mnemonic: *H*elpful errors/warnings). When -H is set, the optree would
be generated with a sufficient amount of bloat that it could report the
errors/warnings at the exact spot they occur, even down to reporting the
appropriate failure line in a multiline statement. We don't worry about
bloat or slowdown, because the assumption is that -H is only used during
debugging or when speed doesn't matter, and it will be turned off when the
code goes to production.
Separate from the above idea, I would like to debate whether -H
should be on or off by default. Either way has advantages and
disadvantages:
-on by default:
PRO: newbies have an easier time,
one-offs and short programs are easier to debug;
CON: p526 must insert a -H into older programs in order to
keep them running at the same speed,
experts who don't want this functionality (will there be
such people?) must type an extra 2 characters into every script.
-off by default:
PRO: p526 doesn't have to add a command line switch,
those who don't want the functionality don't have to type
the extra 2 characters;
CON: people who DO want the functionality (probably the
majority) will need to type an extra 2 characters
Dave
