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

From: Eric Niebler (eric_at_[hidden])
Date: 2008-03-17 20:35:41

Markus Werle wrote:
> A document "The design and evolution of 
> boost::XXX" would boost C++ development even more than using the library
> itself. This is why boost rules say the documentation must contain a
> design rationale (wink, wink).

You mean like this?
http://boost-sandbox.sourceforge.net/libs/proto/doc/html/boost_proto/appendices/rationale.html
(wink, wink)

I guess I could add a blurb there about the naming convention.

<snip>
>> What about transforms is
>> killing you? Is it something fixable, in your opinion? Or just the steep
>> learning curve?
> 
> The steep learning curve only. I am one of those who appreciates
> lovely step by step explanations like your FOREACH paper.
> That's how all things should be explained ... yes, I am asking 
> too much here.
> 
> I see that transforms will help to implement simplify algorithms,
> so I really need them. What kills me is to know it is there, but 
> I get no grip on it.

OK, I'll see if I can rework the transformation section to make it more 
approachable. This is an inherently hard topic, though.

> I was just about to request the ban of binary_expr from the docs.
> For you it is probably nice to have the shortcut, but again this
> is a shortcut from good old times when expressions had a maximum arity
> of 2. 

That happens not to be the case. And what's wrong with shortcuts?

> IMHO the basic expr<> typedef should be provided everywhere 
> in order to ease mental access to the library. 
> I found myself forcing compiler error messages, just to obtain the 
> structure.

Why? There are a lot of largely irrelevant details in the actual type of 
an expression, like the use of argsN<> and ref_<>. I don't see any 
advantage in exposing users to all that in the docs, or forcing users to 
type that in their code.

> Please rework "Expression Construction Utilities" such that you simply 
> add the expr<> version where it is missing, e.g. at 
> 
> // expr_type is the same as this type:
> typedef
>     proto::binary_expr<
>         MyTag
>       , proto::terminal<int>::type
>       , proto::terminal<char>::type
>     >::type
> expr_type2;
> 
> BOOST_MPL_ASSERT((is_same<expr_type2, expr_type>));
> 
> PUT ANOTHER TYPEDEF AND ASSERT HERE OR BETTER: REPLACE

I could do that, but these utilities are provided expressly so that 
users never have to be troubled with the actual expr<> type, which can 
be complicated. Like I said earlier, in NONE of the examples does the 
expr<> type appear. If you're dealing with expr<> directly in your code, 
you're working at a very low abstraction level. And your code is 
probably wrong ... there are expression types that are not expr<>, such 
as a type that uses extends<>.

Is it possible that your considerable experience with expression 
templates is leading you to take too keen an interest in the 
proto::expr<> type? In Proto, it's largely a detail.

> I think this is the beginning of a beautiful friendship :-)

Round up the usual suspects. :-)

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