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.