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.
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<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
> 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.
-- Eric Niebler Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk