Benjamin Goldberg <[EMAIL PROTECTED]> writes:
> > Normal processors also don't have setline and setfile operations. They
> > use an extra segment in the *.o file, which is only used by the
> > debugger. This could also be done in parrot.
>
> 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?
In principle yes. But as they are no opcodes any more they should not
look like ones. They should be written .setline or #setline
>>> #line 17 "sourcefile.p6"
> I don't like this syntax -- it sounds too easy for someone to write a
> comment like:
>
> #When this was in the original foobar language, it was on
> #line 17
>
> And have it interpreted as a directive, when the author meant for it to
> be just a comment.
from the point of the bytecode this is just a comment. No different
bytecode is generated with or without this line. Only for the
debugsegment gets other information.
> There's no reason not to have the directives look like ops (setline,
> setfile).
No they should not look like ops. They are no ops.
They might look like macros .setfile, macros can evaluate to nothing.
> Oh, and you could have get{line,file} directives, which end up
> translated as being simple "set" ops, using the info generated by the
> set{line,file} directives.
Same here. Use .getline macros which are expanded to a set
operation. Or better use a .currentline macro which expands to the
current line. Much like the __LINE__ macro in C.
bye
boe
--
Juergen Boemmels [EMAIL PROTECTED]
Fachbereich Physik Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
