[EMAIL PROTECTED] writes:
> Nicholas Clark <[EMAIL PROTECTED]> writes:
>
> > I think that it has practical uses for other, dimensionally inferior
> > languages. It would often be nice to know which bit of this line:
> >
> > } elsif ($host =~ /([^.]+\.[^.]{3}$)/ || $host =~
> /([^.]{4,}\.[^.]{2}$)/ ) {
> >
> > generated the undefined warning
>
> Even in C this things happen.
Could we get expression-level tagging by *character range* rather than
just line? Could be sweet for visual debuggers--hilight the expression
that's about to execute, even if the expression spans lines.
e.g., stepping through $x = 1 + f($y{z} + 3):
$x = 1 + f(%y{z} + 2)
^---^
^-------^
^----------^
^--------------^
^-------------------^
Using just columns would get you this...
$x = 1 + f(%y{z} + 2)
^
^
^
^
^
And the question, "Why'd the step button do nothing that first time?"
Or maybe this...
$x = 1 + f(%y{z} + 2)
^
^
^
^
^
And the question, "Huh?"
Also good for setting breakpoints inside of behemoth Perl statements--I
have some function calls which are quite legitimately several pages
long--interpolations inside of heredocs, lots of parameters, etc. (I
consider it good style; the parameter "comb" much is clearer and more
succinct than building the equivalent parameter hash with multiple
statements. And it'll only get more attractive when P6's yummy new $()
makes interpolation even more convenient and powerful.) Not that a
debugger's ever worked worth snot with Perl 5, so anything's better than
what's going on now.
Speaking from some experience as a user: .NET does expression-level
hilighting, and it's WONDERFUL when it works. However, it seems to use
simple character offsets, which leads to it frequently going awry when I
make a change to the file. It's always seemingly either FABULOUS or
completely broken. Maybe character offsets from beginning of line would
be a less fragile. Or maybe stuff the whole of the source files into the
debugger segment--there's the fragility problem completely solved,
regardless of the use of line offset or file offset. (Of course, PIR
can't do that when just fed an IMCC assembly file...)
Seems straightforward for the compiler to emit character ranges as it
visits AST nodes. Would wind up with lots of line directives--but
there's no way around there, and it's not so hard.
$x = 1 + f(%y{z} + 3);
01234567890123456789012
0 1 2
TREE OP PIR
%y "z"
\ / #file -
{ } 2 { } #line 1[11] 1[16]
\ / set P3 = P2["z"]
+ + #line 1[11] 1[20]
| new P4, .PerlInt
| add P4, P3, 3
1 f() f() #line 1[9] 1[21]
\ / ... P5 <- f(P4) ...
x + + #line 1[5] 1[21]
\ / new P5, .PerlInt
\ / add P5, 1, P5
= = #line 1[0] 1[22]
set P6, P5
This also gracefully degrades to simple line numbers, because #line n
would be trivially equivalent to #line n[0] (n+1)[0]. Good for lazy
compiler authors, or for distributing pbc files with debugging segments
someplace between NONE and 20-bytes per expression + source code.
(That's 20 bytes: { int bytecodeOffset, begLine, begChar, endLine,
endChar; }.)
--
Gordon Henriksen
IT Manager
ICLUBcentral Inc.
[EMAIL PROTECTED]
P.S. - On column numbers, could we try to avoid having compilers be
aware of tab width settings?
