Leopold Toetsch wrote:
>
> Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
>
> > In other words, setline and setfile ops in source don't translate to
> > actual ops in the bytecode, but instead translate to additions/changes
> > to the debugging segment?
>
> Exactly. (+ C<setpackage>, which isn't done yet)
>
> > I like the ideas of a range of characters, and of variable amount of
> > information. So, how about multiple setline variants?
>
> setline \d+
> setline \d+ '[' \d+ (',' \d+)* ']'
>
> The brackets have the char (range) info, the first one is used to count
> dimensions.
Ok.
> > setline_i Ix # the next line is x, each succeeding line increases.
>
> The HLL doesn't know, how many ops one source line will need.
Not *normally*, but if it's including code which is already literal
assembler, it does: Imagine a version of lex/yacc wherein the the blocks
of code you give are imcc or pasm (instead of C). Clearly, there's one
op per line of source.
> > There'd be a corresponding get* function for each of these except for
> > setline_i (for which it wouldn't make sense), which would get
> > translated at compile time to "set Ix, 12" or whatever. There should
> > be a C-code level interface to go (at runtime) from a pointer to
> > bytecode (or from a bytecode offset) to a file, line, or range of
> > lines, or ... with columns; this would be useful for debuggers.
>
> Yep.
>
> leo
--
$a=24;split//,240513;s/\B/ => /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print "[EMAIL PROTECTED]
]\n";((6<=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))&&redo;}
