Hans-Peter Diettrich wrote

Some questions about tfileposinfo position variables: 1) What's the difference between current_tokenpos and current_filepos? Normally the scanner updates both vars to the same value...

Current_tokenpos means the scanner position, current_filepos the compiler position in the code. While scanning and parsing, they are indeed equal. But when compiling a procedure, after parsing current_tokenpos is at the end of the procedure. Now, e.g. when the code is generated, current_filepos is set back to the positions where the node were read (the position is stored in tnode.fileinfo). So e.g. in case of an error, the compiler displays the correct location of the error.

2) What's the meaning of the tailineinfo.fileinfo value? The default constructor inits fileinfo to current_filepos.

The position where tailineinfo was created.

3) What's the meaning of the tnode.fileinfo value? The default constructor inits fileinfo to current_filepos.

See above.

4) What's the meaning of the tsym.fileinfo value? The default constructor inits fileinfo to current_tokenpos.

See above.

5) Some (parser) procedures modify current_tokenpos/filepos temporarily, and restore the old values later. What's the purpose of such changes?

To get correct file positions in debugging code and error messages.

Some questions about tfileposinfo position variables:

1) What's the difference between current_tokenpos and current_filepos? Normally the scanner updates both vars to the same value...

2) What's the meaning of the tailineinfo.fileinfo value? The default constructor inits fileinfo to current_filepos.

3) What's the meaning of the tnode.fileinfo value? The default constructor inits fileinfo to current_filepos.

4) What's the meaning of the tsym.fileinfo value?
The default constructor inits fileinfo to current_tokenpos.

5) Some (parser) procedures modify current_tokenpos/filepos temporarily, and restore the old values later. What's the purpose of such changes?

DoDi

Thanks, that explains a lot :-)

So every temporary change of current_tokenpos should be considered wrong? According to your above description I'd make current_tokenpos a read-only property of the scanner...

DoDi

I'am not sure what e.g. generics do with it.

Me 2 :-(

Therefore my questions about the values in concrete classes, whose answers could shed a light on the according use in macro expansion and generics. Probably generics require both information, about the locations of the declarations and their extensions, in order to generate useful error messages. But I never used generics myself, and consequently don't know anything about possible problems...

DoDi

Generics need to replay tokens with their position for debugging purposes.

Best regards,
Paul Ishenin

Generics need to replay tokens with their position for debugging purposes.

I.e. the tokens have to be stored and replayed with their original positions. Most probably the current_filepos should not be modified during replay (in contrast to normal token scanning)?

The replay procedure is a bit cryptic, since positions are encoded in special tokens, and it's not obvious in which places such tokens occur in the stored token stream.

DoDi