Re: [boost] [guidelines] why template errors suck

Subject: Re: [boost] [guidelines] why template errors suck
From: Joel Falcou (joel.falcou_at_[hidden])
Date: 2010-09-27 02:45:27

On 27/09/10 08:14, Sebastian Redl wrote:
> I don't really see how Proto parse trees are an abstraction. They feel very concrete to me. The abstraction here are heterogenous trees of arbitrary branching level - Proto really doesn't enforce much beyond the ability to get the arity, children and value of a node. Spirit adds requirements on the nodes, e.g. that they have to be able to process input text (for parsers), and expose an attribute type. All of this can be modeled.
> Proto grammars essentially extend the basic Proto tree node concept by setting requirements on the arity, value and children of the node. The main problem here is that grammars are a very succinct way of specifying these requirements, while the equivalent concept language would be quite verbose. In particular, alternative grammars - proto::or_ - are very hard to express, because concepts don't have a natural way of expressing "concept A is fulfilled if B or C are fulfilled, and it doesn't matter which". The reason for this is that concept are designed to place requirements on types that allow C++ code to be validated. You can't write a template function that makes use of the requirement "either binary plus or binary minus will compile, but either may fail", not without first determining which and then dispatching to helper functions. Which is exactly how Proto grammars would be implemented. And that's just a very inefficient way to do it.

I quite agree. In my own poor layman use of cocnept in another proto 
based library, I never had to specify anything proto in my concepts.
NT2 concepts of EvaluableExpression, ElementwiseEvaluableExpression etc 
just rely on outer interface availability. Heck if I had to capture the 
whole grammar of Matlab in a concept I owuld have died already :/