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

Subject: Re: [boost] [guidelines] why template errors suck
From: Sebastian Redl (sebastian.redl_at_[hidden])
Date: 2010-09-27 02:14:05

On Sep 26, 2010, at 7:31 PM, Eric Niebler wrote:

> On 9/26/2010 9:44 PM, David Abrahams wrote:
>> On Sep 26, 2010, at 8:55 AM, Eric Niebler wrote:
>>> If there are template constraints not
>>> practically expressible in concepts, then aren't concepts broken?
>> 
>> Not necessarily.  Concepts are not about expressing arbitrary template constraints.  They're about describing abstractions.  One might say that if you can't figure out how to write a concept for a template parameter, you don't understand the abstraction it's modelling.
> 
> I understand the abstraction perfectly well. It's a strongly-typed tree
> that conforms to a grammar. I haven't a clue how to express that as a
> concept. It's not a reflection of my poor understanding of my
> abstraction. It reflects my poor understanding of concepts. I'm
> sincerely asking for help trying to understand this.

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.

Sebastian