Re: [boost] Re: ATTN: All Developers Interested in Boost.Preprocessor

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2003-04-30 22:46:53

Rene Rivera wrote:
>> The only problem tokens are , ( ) # and ## (as well as %: and %:%:).
>> Everything else is fine.  The problems with those tokens arise only
>> from the fact they have special meaning to the syntactic/semantic
>> model of the preprocessor.  As I said, we can work around this
>> problem, but the workaround is not local--i.e. it makes it necessary
>> to apply the workaround globally an any situation where you might
>> want to pass one of those tokens.
>
> I don't see what difference the problem tokens are. If the
> preprocessor
> knows to not parse a specific token sequence you tell it how can it
> be a problem?

Well, how about this:

#define STR(x) STR_(x)
#define STR_(x) #x

STR( + ) // okay:  "+"
STR( ( ) // error!
STR( , ) // error!

It is impossible to stringize the comma or one of the parentheses by itself.
Best you can do is this:

STR( ()  ) // okay:  "()"
STR( (,) ) // okay:  "(,)"

...which is not what is wanted.

>> #define COMMA() ,
>
> Or define it as:
>
>     #define COMMA #escape ","

Yes, or just use __comma__ as Vesa suggested. :)

>> And then pass it through other macros without invoking it:
>>
>> MACRO( COMMA )
>
> No need if defined as above.

Yes, same as __comma__ also.  The point being that you only need __comma__,
__lparen__, and __rparen__.  You don't need it for anything else.

> You could do:
>
>     MACRO( #escape "+" )

Yes, but want we want is:

MACRO(+)
MACRO(__comma__)

For the common case where the comma or parentheses aren't needed for further
expansion.  If token-pasting was well-defined for unrelated tokens, you could
force the invocation early in a general fashion if desired.

>> Because you'd get this:
>>
>> R(0) +() R(1) +() R(2)
>
> And would get the desired:
>
>     R(0) + R(1) + R(2)
>
>> So, you have to either 1) make a PLUS() macro or 2) use some type of
>> invocable identity macro:
>>
>> #define COMMA() ,
>>
>> #define EMPTY()
>> #define IDENTITY(x) x EMPTY
>>
>> MACRO( COMMA       ) // R(0) , R(1) , R(2)
>> MACRO( EMPTY       ) // R(0)   R(1)   R(2)
>> MACRO( IDENTITY(+) ) // R(0) + R(1) + R(2)
>> MACRO( IDENTITY(;) ) // R(0) ; R(1) ; R(2)
>
>     MACRO( #escape "," ) // R(0) , R(1) , R(2)
>     MACRO( #escape " " ) // R(0)   R(1)   R(2)
>     MACRO( #escape "+" ) // R(0) + R(1) + R(2)
>     MACRO( #escape ";" ) // R(0) ; R(1) ; R(2)

MACRO(__comma__)
MACRO() // placemarkers from C99
MACRO(+)
MACRO(;)

>> Etc.
>>
>> In other words, the "fix" takes over everything that isn't the
>> problem to begin with.  I.e. it is intrusive.  There are other
>> options, of course, but all
> of
>> them have some type of intrusive drawback--for instance what if you
>> wanted "((" as a delineator...
>>
>> Late-bound expansion for __comma__, __lparen__, and __rparen__ would
>> *partially* solve the problem.  However, it would not fix the
>> problem completely.  For instance, if the above result was used as
>> arguments to an other macro:
>>
>> #define OTHER(x) OTHER_I x
> Did you mean #define OTHER(x) OTHER_I(x) ???

Yes, sorry.

>> #define OTHER_I(a, b, c) a b c
>>
>> OTHER( MACRO(__comma__) ) // error
>>
>> The same caveat applies to parentheses.  They permanently become
>> "non-operators" to the preprocessor which can be a major limitation.
>
> Ahh (after a few minutes of contemplation ;-)... I see that problem.
> Basically there is no general point of macro replacement that will
> solve it in all cases. Currently it's "replace asap", and with the
> __comma__ & #escape it's "replace last".

(I should say, BTW, that given a "strict" preprocessor, I can cause a delay in a
macro's invocation through virtually any number of rescannings.  Meaning that,
if I can count the number of rescans for a given argument (which I can also do),
I can delay the invocation of COMMA all the way through to the correct point and
have it expand automatically.  However, that is dangerous and ridiculously
fragile.)

> OK, so here's another idea. Let the macro writer/user specify where
> the replacement point is. With lets say an #eval command. The problem
> example above could then be implemented as:
>
> #define OTHER(x) OTHER_I( #eval x )
>
> Or for the user...
>
> OTHER( #eval MACRO(#escape ",") )

The whole point, IMO, is to avoid the need for the intrusive syntax in as many
places as possible--both in the implementation and in the interface.  __comma__,
__lparen__, and __rparen__ are the only useful ones--unless you mean to say that
#escape "..." can include arbitrary macros expansions etc. that are delayed
until the last possible moment?

Paul Mensonides