Hi! This is a minor issue, but nevertheless I'd like to share my opinion on this: The longer I think about _arg0 and its brothers and sisters the more I get the impression that they should be banned from proto. 1. Especially the typedefs for _arg, _left and _right should be removed from the library, because they duplicate the interface and bring more confusion than convenience. While rereading through the docs I tried to replace those typedefs with their arg_c<> substitutes before my inner eyes - et voila, the approach to the design is much easier now. I think _left and _right are in for historic reason (you always start thinking about ET as binary trees, e.g. while reading Veldhuizen's paper), but one thing should have one name in a general purpose library. Also it is a very good approach to proto, to repeat 100 times every morning that any operator is nothing but an oddly written function call. For function calls it makes no sense to talk about left and right. So a minor argument is didactic clarity. The major argument is: No fat interface here! This is not std::string, this is boost::prior(std::etl). Summary: I strongly vote against _arg, _left and _right. 2. From a user's point of view I still cannot see the advantage of using argSOME_NUMBER instead of arg_c<SOME_NUMBER>. Couldn't you make arg_c<XX> a first class citizen of namespace proto? So even if it makes it easier to write the boilerplate parts of proto itself, names based on MACROS are still evil enough to remove them from the _interface_ and for me _argSOME_NUMBER is part of the interface. IMHO templates with integer arguments scale well enough not to introduce PP garbage here. I have the suspicion that _argSOME_NUMBER is only inside because you have all those BOOST_PP_MAKE_MY_CODE_WRITE_ONCE_NEVER_UNDERSTAND_LATER. Note that this is not a show stopper for me, I propose the ban, but in contrast to _arg, _left and _right I can live with those, since transform::arg_c<I> is at hand and I will use those right from the beginning and ban _arg0 from my own code consequently. <kidding>Eric, you will only have to pay for all those extra "transform::" I have to type all the time. Let's say $0.02 for every occurence ... OK?</kidding> Eric, please classify right from the beginning, whether issue #2 takes on "bike shed characteristics" and/or disclose your rationale for _argSOME_NUMBER. Markus