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

From: Rene Rivera (grafik666_at_[hidden])
Date: 2003-05-01 10:01:43

[2003-04-30] Paul Mensonides wrote:

[snip]

Understood :-)

>Rene Rivera wrote:
>> 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

I just don't see how you can avoid any "intrusive" syntax. You just can't
write a language (PP in this case) that "does what you mean, not what you
say"... grammar gets in the way ;-)

>--unless you mean to say that
>#escape "..." can include arbitrary macros expansions etc. that are delayed
>until the last possible moment?

No totally sure what arbitrary macros you mean. But yes, the "escaped"
token-string can be anything and it would only get inserted/evaluated as the
_last_ step. So it would have to unwind the parse recursion, and then insert
the escaped token-string. And with the #eval you could control when any
currectly accumulated #escape token-strings are inserted.

-- grafik - Don't Assume Anything
-- rrivera_at_[hidden] - grafik_at_[hidden]
-- 102708583_at_icq