Am Fri, 13 May 2011 15:00:26 +0200 schrieb Hans-Peter Diettrich <drdiettri...@aol.com>:
> > A general decision is required: do we *want* explicit or implicit > macro expansion? Yes, I see this point too, i thought it is better to have a restricted form of macro processing introduced by means of an compiler directive, then nothing. The idea of doing it the {$I macname(paramtext)} way was born as an anticipation of the efficiency objection. Further thinking brings it out - for me - that it would be not that bad. Using an macro dp(x,[y,z]) is not so far from {$I %dp(x,[y,z])} if it prevents the refusal of the whole thing. The efficiency argument is an other. And some kind of aesthetic to separate pascal from preprocc code. The point you mention is that it is this way impossible to change the behavior of the pascal code outside the macro: Thats true you have to put it in as an parameter. I do not know if this is that bad. Any example where it makes really a difference? > The same effect can be achieved by an invocation like > dp(x,[y,z]); > just as in Format(). I think only in this special case, because of the ellipsis in that array of const, which is build-in. What if you do some other processing, for example something with lists of names or sets, something where in pascal no ellipsis is allowed? If that dp takes x and [y,z] for his arguments you will need to do it this way: dp(x,'[y,z]') and inside the macro text some sort of tokenization operator because of the comma. Or an other mechanism of finding the parameters of an macro invocation, which will then be less effective. > Macros should be stored as tokens, compatible with the scanner's > Record and Replay methods. The preprocesor must not distinguish > between identifiers and reserved words, see the implementation of > context-sensitive directive handling. You mean the expanded text? That`s clear an internal macro processor should do so. But the tokens of the macro processor himself are completely different from pascal ones. That depends on how it fits in the scanner and the file handling and error reporting too. I think one possibility would be to break the tokens down to chars and let the scanner do his work like on an included file. Less effective, but better then rewriting the scanner. > ... The detection of macro > identifiers can be done in the keyword recognition, eventually > resulting a tkMacro token. Yes, the point was to show how it can be done without even the need for this kind of recognition. But I see from your first annotation that it leads to an real restriction. I am not ready with that. > Macro arguments can be stored as identifiers, which then are found > (during macro expansion) in the top-level symbol table. Eventually a > new symbol type "MacroArgument" has to be introduced, that enforces > argument substition, stringification etc. The idea was to remove the macro parameter names from the macro text body to prevent some kind of recursive recreation of macro parameter names during the expansion of the macro body. Of course are the names stored in some kind of symbol table entry. > IMO a macro parameter list should follow the language conventions, so > that a procedure identifier can be replaced by a macro identifier, > forcing macro expansion instead of generating an procedure call. I.e. > the preprocessor is a *postprocessor* for scanner tokens. > That's one more reason to position the preprocessor *after* the > scanner, or at the end of the tokenizer to prevent another call level. Yes in both respects. I prefer the solution without that ugly %, too. If it is not possible to incorporate it in the compiler, then it would be a true preprocessor, but all the work of token parsing is done twice. ;( > As mentioned at the begin, I don't like special syntax for macro > identifiers, invocation and parameters. The worth of your attempt, to > speed up macro processing, must be determined after it has been > implemented. IMO similar effects can be obtained by removing (not > introducing) some of the C preprocessor misfeatures, which have not > been considered yet. Candidates are recursive macro expansion and > (also recursive?) expansion of macro parameters, as well as > concatenation. I will think about. Recursive expansion is a candidate for not using it. The question is, influences this feature the efficiency of the expansion process, even if it is not used? I`m not sure this day. Thanks a lot for your really helpful thoughts. Best regards Jörg _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel