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
