[boost] [proto] minor issue: unnecessary typedefs _arg*

From: Markus Werle (numerical.simulation_at_[hidden])
Date: 2008-03-15 07:18:41

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