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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
