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

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2003-05-01 15:25:49

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

You can't avoid it entirely.  As you say, the grammar...  However, you can limit
the intrusiveness to only those three tokens and only when they are used.

>> --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.

What I meant was something like:

#define ID(x) x
#define MACRO() 123

ID( #escape "MACRO()" )

Are you suggesting that the result should be "MACRO()" or that the
invocation/processing of the escaped string should be deferred until after
top-level scanning moves past it (conceptually)?  In that case, it would expand
to "123".  BTW, I like the second one better, but only because I can think of,
as usual, pathological usages of it. ;)

Regards,
Paul Mensonides