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

From: Eric Niebler (eric_at_[hidden])
Date: 2008-03-17 13:51:00

Markus Werle wrote:
> Eric Niebler wrote:
>> proto::X is a function, 
>> proto::result_of::X is a metafunction that computes the result type of
>> proto::X, proto::functional::X is the function object equivalent of X,
>> and proto::transform::X is the primitive transform equivalent of X.
> 
> I guess that is why I get lost all the time: I read the code in the docs 
> and cannot guess from the name whether this is a typename or a 
> function or whatever and which namespace it belongs.

The docs should use qualification where it could be unclear what a name 
refers to. I can make a pass through the docs to double-check, but if 
you can point to the places where a lack of qualification led you into 
trouble, I'll fix them.

> Just a daydream: What happens if it is this way:
> 
> proto::X is a function, proto::result_of::X_r is a metafunction that
> computes the result type of proto::X, proto::functional::X_f is the
> function object equivalent of X, and proto::transform::X_t is the primitive
> transform equivalent of X.
> 
> Do we loose anything? Do we run into trouble?

Well, it would be inconsistent with established practice within Boost. 
Fusion, for one, uses a similar naming scheme.

Spirit-1 used a naming scheme like the one you suggest (trailing "_p" 
means parser, trailing "_a" means action, etc.). Spirit-2 is dropping 
this in favor of namespaces, like Fusion and Proto. I believe that was 
in response to feedback from Dave Abrahams. Perhaps Dave or Joel could 
chime in on this issue.

<snip>

Re: the _argN transforms ...
> I assumed they were generated by a macro until BOOST_PROTO_MAX_ARITY ...
> I was preaching against that (inexistent?) macro.
> Now I took a look at proto_fwd.hpp and found they are made by hand
> and stop at 9. So now I really have a problem: 
> what happens if I need an arity of 120?

Ha! I imaging you'll need longer than the heat death of the universe to 
compile your program, but ...

... you're absolutely right, for the _argN transforms, N should go up to 
at least BOOST_PROTO_MAX_ARITY. I'll need to add a little PP magic.

> struct MakePair
>   : when<
>         function<terminal<make_pair_tag>, terminal<_>, terminal<_> >
>       , make_pair(
>             _arg_c<0>(_arg_c<1>)
>           , _arg_c<0>(_arg_c<2>)
>         )
>     >
> {};
> 
> is OK for me, but I understand your intention.
> Those transforms kill me, but I need them.

I don't want my code to hurt or kill anybody. What about transforms is 
killing you? Is it something fixable, in your opinion? Or just the steep 
learning curve?

> The advantage of those numbers is: proto is a typelist tool.
> If you see the index you do not mix it up.
> With _arg I always have this second, where I translate it back to
> _arg_c<0>, etc. At least during my approach to the docs those 
> aliases did not help me (but I do not fear nested templates).

I see your POV, but I see it a different way ... Proto provides a 
domain-specific language for processing C++ expression trees. Within 
that domain, unary and binary expressions are the norm, so I provide 
abstractions for dealing with them in a more natural (IMHO) way.

I'd be interested in other people's opinions.

> If those _argN scale up to N=300 or more I will not vote against them.
> Otherwise if 9 is the maximum, I have a problem with that solution.

Agreed.

-- 
Eric Niebler
Boost Consulting
www.boost-consulting.com