Re: [boost] [Proto] Review

From: Eric Niebler (eric_at_[hidden])
Date: 2008-04-01 13:44:31

David Abrahams wrote:
> Eric Niebler wrote:
>> 1) The aliasing issue (proto::_left as a typedef for
>> proto::transform::left) will be resolved by eliminating the "transform"
>> namespace and everything in it.
> 
> I'm sorry, I don't recall having any aliasing issue.  Can you relate
> this to something specific I wrote?

Sure, our exchange went like this:

>> proto::transform::foo is the primitive transform, and 
>> proto::_foo is an alias for proto::transform::foo.
> 
> Hmm, that's hard to keep track of.  If you dopped the alias it would be
> a little simpler.

I suggest dropping the proto::transform::foo and keeping proto::_foo.

>> 2) The "functional" namespace will be renamed "functor".
> 
> That rubs me the wrong way, but it may not be worth fighting the tide.
> The "official view of the C++ community" as I understand it, is that
> ever calling function objects "functors" was a big mistake because that
> term already has another meaning in category theory which as you know
> spills over into type theory and thus CS, which is even expressed as a
> language construct in ML.  That said, people don't seem to have stopped
> saying "functor" when they mean "function object," and I doubt *I* can
> stop them.  I guess the question is whether Boost will contribute to
> that terminology problem or help solve it.

OK, but I didn't like your suggestions of "function_obj" or "object". So 
now I leaning back toward "functional". There is some prior art for that 
term: the <functional> header is where the std:: function objects live.

It would be nice to come up with something we can all agree on. I'm 
going to press to get function object equivalents to Fusion's free 
functions. They should be in the fusion::functional namespace if we 
decide to go that way.

>> 5) You can override an expression's domain with
>> "proto::as_expr<Domain>(expr)". 
> 
> "You" meaning "end users of libraries built with proto?"

Yes.

>> This gives a way to mix expressions from
>> different domains in the same expression.
> 
> I take it as_expr already exists?

Correct, and it was undefined what as_expr<D>(e) does when e is an 
expression in a domain other than D. This just gives it an obvious and 
useful meaning: treat e as an expression in domain D.

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