Re: [Boost-users] [proto] Matching grammars in the presence of adapted types

Subject: Re: [Boost-users] [proto] Matching grammars in the presence of adapted types
From: Eric Niebler (eric_at_[hidden])
Date: 2010-06-10 13:05:50

On 6/10/2010 11:57 AM, Sebastian Redl wrote:
> 
> So I've figured out the problem. Basically, I was doing something like
> this:
> 
> ---------------------
> 
> struct SmartContext {
> 
> template<typename Expr, typename Enabler = void>
> struct eval;
> 
> template<typename Expr>
> struct eval<Expr,
>   /* something here to catch arity == 0 */> {
>   /* implementation for terminals */
> };
> 
> template<typename Expr>
> struct eval<Expr,
>   /* something here that looks at the children of Expr */> {
>   /* one implementation for non-terminals */
> };
> 
> template<typename Expr>
> struct eval<Expr,
>   /* something else here that looks at the children of Expr */> {
>   /* another implementation for non-terminals */
> };
> 
> };
> 
> ---------------------
> 
> Unfortunately, those specializations are all tested at the same time.
> Thus, even for terminal expressions, the stuff looking at the children was
> evaluated. 

Using SFINAE in proto context types means you should probably be using
transforms instead. Contexts are useful when you can dispatch on node
tag type. Anything fancier and transforms are the way to go.

> However, the "child" of a terminal is the underlying value
> implementation, so this stuff tried to access the value implementation as
> if it was an expression. Thus the compilation errors.
> 
> Is there a particular reason why terminals are implemented this way? Does
> it make Proto implementation considerably more convenient? Because if not,
> it would be nice to change it so that proto::child() and proto::value() are
> not synonyms, but instead simply don't compile for terminals and
> non-terminals, respectively. That would have helped a lot in detecting this
> error.
> 
> Actually, a static_assert would suffice. Something like:
<snip>

I'll consider adding it, but I worry about breaking people who are
unknowingly and incorrectly relying on this behavior. Hmm...

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com