Re: [boost] Review Request: Variadic Macro Data library

Subject: Re: [boost] Review Request: Variadic Macro Data library
From: Edward Diener (eldiener_at_[hidden])
Date: 2011-02-20 11:52:20

On 2/20/2011 10:43 AM, Paul Mensonides wrote:
> On Sun, 20 Feb 2011 09:55:14 -0500, Daniel Larimer wrote:
>
>> I think that you have identified a very good use for the variadic
>> argument, but I am not sure that it completely conflicts with the ideas
>> present in the VMD library.  So unless providing utilities to convert
>> from VA_ARGS ->  SEQ, LIST, Array, etc somehow prevents you from
>> expanding the FOR_EACH macro like you described, I would tend to favor
>> an incremental approach.  Don't hold up useful functionality because
>> there is more useful functionality you could add.
>>
>> Reworking the whole of the PP library with VA support sounds like it
>> would significantly delay the adoption of some very useful tools.
>
> I don't have a problem with the particular macros.  I do have a concern
> about establishing practices which I don't consider to be terribly good
> practices.
>
> I'd really like to see a use case that is different from what I'm
> envisioning.  What I'm envisioning is something like:
>
> #define ALGORITHM_B(...) \
>      ALGORITHM_A(DATA_TO_SEQ(__VA_ARGS__)) \
>      /**/
>
> ALGORITHM_B(a, b, c)
>
> I don't find that use case compelling, and that point of view is based on
> heavy experience utilizing variadics.  When I was initially writing chaos-
> pp, I went down this path, but ultimately rejected it.  It simply doesn't
> scale and results in other intrastructure that doesn't scale.

I could not agree more that it does not scale well for general use, and 
I understand that it is not the way you would want to extend the pp-lib 
to use variadic macros internally.

But consider just the case where an end-user is doing some pp 
programming for their own use, and the use of other end-user programmers 
using their library, which may have nothing to do with pp programming 
itself. They want to present a macro interface which uses variadic 
macros rather than, let's say, Boost PP sequences. They are doing this 
just to make their interface look easier to use, ie. 
SOME_MACRO(a,b,c,d,etc.) rather than SOME_MACRO((a),(b),(c),(d),etc.). 
In that case creating some internal macro like ALGORITHM_B ( which is of 
course a highly simplified version of using variadic macro data 
internally ) above is purely a matter of their own convenience. It's not 
meant to be part of some highly reusable code but just for their own 
specific purposes. In that situation I see nothing wrong with it on a 
technical basis. That it does not scale well in the sense that it is 
integrated into a whole system of uses of variadic macros I can see. But 
its only purpose is to get away from using variadic macros and to use a 
pp-lib data structure instead, while still presenting an external 
interface to the end user which uses variadic macros.

I myself have done this in my TTI lib. I allow an alternative macro for 
some functionality which uses a variadic macro, and I take the data and 
pass it on internally to inner processing which uses a pp-lib data type. 
I am not trying to do internal pp programming with variadic macro data, 
as the pp-lib data type is much richer in functionality. Even in cases 
where I might internally use variadic macro syntax for my own library I 
would not attempt to do anything with the data that is in any way 
complicated, but just use it as a syntax convenience for myself. But 
even in that case I find it has little to offer and pp-lib data types, 
once one is comfortable using them and their syntax, is much better.

Wanting to present variadic macro syntax as a service for end-user 
programmers was the main motivation for my VMD library. I believe others 
have also found the using of variadic macros as an end-user macro 
interface also useful.

>
> To attempt to clarify, something like
>
> ALGORITHM_A(DATA_TO_SEQ(a, b, c))
>
> is not really a problem, but the existence of the ALGORITHM_B definition
> (as a non-local construct) *is* a problem.