[fpc-devel] Macro Processing

[Hans-Peter Diettrich]

Michael Van Canneyt schrieb:

> In short: No, it is better to keep that particular box of pandora closed.

It may be worth a try.

> None of the more "modern" languages implement macros, and this is for 
> good reason.

Right, preprocessor support can be *added* to every language, 
introducing macros, directives, conditional compilation etc.

The only issue is performance, which led to an integration of 
preprocessing features into *existing* scanners and parsers, with the 
most simple and least intrusive placement of an preprocessor between the 
scanner and parser, as kind of an token filter. The only requirement may 
be the addition of preprocessor tokens to the scanner, if ever.

Traditional Pascal added compiler directives, hidden inside comments. 
It's only a matter of performance, whether these directives should be 
handled immediately at detection of a comment, or after a comment has 
been fully recognized (skipped) by the scanner. Conditional compilation 
also can be implemented outside the scanner, with optional feedback 
instructing the scanner to *not* apply special processing to tokens 
which are skipped by conditional directives. Include directives require 
more support in the scanner, which then must be capable of switching 
between multiple input streams. Macros can be implemented in the same 
way, but it will be more efficient to Record and Replay token streams 
instead of character streams. This recorder also can be implemented 
outside the scanner, an according filter will either return a previously 
recorded token, or else it asks the scanner for the next token.


> Pascal has always existed without macros. It keeps code readable:
> what you read is what you get.
> This is a strength of the language, and should remain that way.

This IMO is no more true, since the introduction of overloaded 
procedures and virtual methods. How often is the reader of some code 
lost in an call to an abstract method :-(

The current directives can already make the code unreadable, with the 
ugly $INCLUDE :-(

> If you want macros, preprocess your code with m4. Or program in C or C++

That's a stupid idea :-(

Where would you put the boundary between useful preprocessing (include 
files, conditional compilation...) and useless preprocessing? For what 
valid reason?

I'd leave that vote to the user. Extended macro support doesn't require 
many changes to the existing compiler (scanner), so that it can be 
implemented e.g. in TScannerFile descendants. The only requirement is an 
agreement, that the scanner interface and preprocessor hooks will not be 
broken by updates to the scanner class. Then everybody can add its own 
preprocessor extensions, without affecting the main stream compiler.

DoDi