RE: [boost] PP: BOOST_PP_IS_SEQ wanted

From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2003-04-15 03:06:13

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

I suppose you meant the opposite.

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

I know, and your willingness to make the library work on these broken 
preprocessors is much appreciated.

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

I would say I don't see how saying "this feature doesn't works on such
and such compilers" leads to a maintenance nightmare. It's definitely
less work for the maintainer, isn't it? Say, if portability wasn't 
one of the important goals of the MPL, I would _gladly_ give up some 
of the workarounds for a simple statement "this doesn't work on broken
compilers such as ...". It would definitely make library's maintenance
way easier.

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

Well, technical feasibility is a different question. What I am opposed 
to is rejection of useful and relevant functionality from the library 
because of "portability fracturing", especially since IS_SEQ is not the 
only primitive that was turned down under that line of reasoning.

As for the above issue, pp-sequences themselves cannot contain that 
kind of data, can they? For instance, I am pretty sure this one will 
fail as well

    BOOST_PP_SEQ_ELEM(0, (a, b, c)(a))

although, strictly speaking, (a, b, c)(a) _is_ a sequence. Frankly, I 
don't think it's an important corner case either. For anyone more or
less familiar with C++ preprocessor it's obvious that the above won't
work, and why. 

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

Hmm, that's kind of news to me. What about the IS_SEQ implementation I 
posted? Is it "unstable" as well?

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

No, it's either alphabetical date or multi-element sequence. 

> Nothing else with work portably. E.g. textual input will fail on 
> several compilers.  

Mine implementation seems to work fine at least on MSVC and Metrowerks.
We don't care about the rest :).

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

I can understand the technical reasons for not including the 
facilities in the library - if that's where it will end up. I am not 
fond of "everything should work on every major compiler" line of 
reasoning - especially considering that many users don't care about
some of those "major" vendors.

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

Well, that's reassuring to hear, because as much as I am excited about
this new work, I would hate to see a drop of support and enhancement
for the "traditional" version of one of the most useful boost libraries 
to date.

Aleksey