Dave Storrs wrote:
>
> 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.
It's not necessarily an all-or-nothing thing. It depends on the level of
optimization requested, as well as the amount of bloat acceptable. It
may turn out that it doesn't blow things up or slow things down enough
to have an explicit flag, so it could be silently modified by the
optimization level instead. It may also be possible to make it a pragma,
though that might be a little weird.
As for what to call it if there is one, -g is the immediately obvious
option. It doesn't stand for anything relevant but is parallel to cc's
-g. -H works for me too. -L would be better (_L_ine numbers), but we
might want to reserve that for some sort of library path. And -l is
taken.
> CON: p526 must insert a -H into older programs in order to
> keep them running at the same speed,
I'd say forget about this constraint. p526's one and only goal is to
make Perl5 programs run correctly. If you want speed, write Perl6 code.
It shouldn't be hard to port Perl5->Perl6 manually. And p526 will
probably spit out Perl6 code anyway, so you can run it with whatever
flags you want.
I'd vote for it on by default, but then the command-line option needs to
be revisited. I don't want -H to turn it *off*. I'd rather have some -O
option (-Onolines?).
