Re: [boost] PP: BOOST_PP_IS_SEQ wanted

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2003-04-14 17:16:02

Aleksey Gurtovoy wrote:
>> It is not an interface macro.  You can use it (e.g.
>> BOOST_PP_IS_UNARY), and it will remain, but I do not want to make
>> interfaces public that don't work properly on all major vendors.
>
> Why? I understand that, as the library author, you would much prefer
> all the facilities work properly on all the compilers (I, for
> instance, wish that was true for MPL as well), but _not including_ a
> generally useful and wanted by real-world users functionality into
> the library because a couple of vendors have broken compilers is
> exactly the strategy I wouldn't expect any boost library to take.

And it is the strategy taken by the pp-lib as well.  The sheer amount of hacks
contained in the pp-lib to make things work on broken preprocessors is evidence
of this.  It contains nearly four separate implementations of the same
thing--just for that purpose.  However:  at a certain point, that level of
'hacking' becomes a maintenance nightmare, as does fracturing portability by
enabling and disabling features on various compilers.

Also, in regards to IS_SEQ specifically, the macro is *unsafe*.  The level of
generality that it implies does not exist without variadics--and even then
things can be ambiguous.  Specifically, in this case, it cannot accept arbitrary
input:

BOOST_PP_IS_UNARY( (a, b, c) ) // error

This is an important concern in preprocessor metaprogramming because it causes
tight bindings between various library primitives and user-code.  Ultimately,
IS_UNARY is a low-level detection mechanism that is part of a "next-level"
preprocessing methodology that is only minimally used even in the pp-lib itself
and only in *very* controlled circumstances.  The pp-lib cannot support this
"next-level" in any general fashion.  Even the use of IS_UNARY, et al, is "dicy"
on Metrowerks and VC++.  It will not work in contexts that are not strictly
controlled, because it directly relies on expansion order--something that is
fundamentally flawed on those preprocessors.  So, in the end, what that means is
that it is unsafe to use in user-code without the same level of hacks that are
used in the pp-lib itself.  The problems with VC++ and Metrowerks are serious
encapsulation issues, which is why you're having the REPEAT + SEQ_ELEM bug, and
if I "publish" macros of this nature, this type of problem will occur more and
more often.  (The "strict" version goes beyond even this "next-level", BTW.)

>> (I assume that you are trying to deal with an "end-of-seq"
>> indicator.
>
> No, I want to distinguish if a parameter passed to a macro is a
> "plain" data or a sequence of "advanced" arguments.

Ah, okay.  BOOST_PP_IS_UNARY will do it for you, _if_ the input is either a
unary sequence or operatic.  Nothing else with work portably.  E.g. textual
input will fail on several compilers.  Also, before any argument goes into
BOOST_PP_IS_UNARY, it must be *forced* to expand on VC++ and Metrowerks.

>> FYI, nil sequences are directly supported in the
>> "strict" pp-lib if using C99 facilities.)
>
> If "strict" PP library makes it in our production environment,
> it's going to be more or less distant future. The need that generated
> my request for IS_SEQ is much more real.

As I said:  the facility exists already but has major drawbacks.  It is not that
I'm not trying to be helpful.  Rather I think it establishes a precendent that I
don't want to have to deal with down the road.

The "strict" pp-lib's primary purpose is as a concept library, a teaching tool,
and an idealistic reference implementation.  Whether or not people actually use
it in a production environment is up to them--i.e. if it is worth relying on a
secondary build tool.

>> The same is true for the identifier comparison.  You can use that
>> implementation, but I don't want fragment the interface of the CVS
>> pp-lib.  If people want more heavy-duty facilities, they can use the
>> "strict" version, which doesn't play around like the CVS version.
>
> Well, I guess that's up to you, but if that's how it is going to end
> up, it would definitely discourage me as a user to provide feedback
> and suggestions about the library we use to solve our day-to-day
> problems, and would push toward taking the current PP library
> "in-house".

Please don't imply that I'm not trying to do as much as I can.  The problems
that I refer to above are the result of a great deal of effort *attempting* to
make this kind of thing work properly and consistently on preprocessors that
exist today.  However, some things I *cannot* hack, or, even if I can, they are
unstable.  In the case of VC++ for example, certain things do not expand when
they should.  This causes other things not to expand when they should, and on
and on.  When you get to something like IS_UNARY, you have accrued several
layers (sometimes many) of expansion that haven't expanded "yet."  Therefore a
forced expansion on VC++ is not good enough, because the expansions are
dependent--an unknown quantity of forced expansions are necessary.  (This
coupled with the fact that VC++ has a nasty "assumption" habit about whether or
not rescanning is necessary.)

Regards,
Paul Mensonides