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

Subject: Re: [boost] [guidelines] why template errors suck
From: Eric Niebler (eric_at_[hidden])
Date: 2010-09-27 10:17:52

On 9/27/2010 2:14 AM, Sebastian Redl wrote:
> 
> 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 I was referring to was the one applicable to the RHS of
Spirit's rule::operator=.

> 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.

Right.

> 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.

Not quite. At the point at which it is assigned to a rule, the RHS is
not yet a parser; i.e. it cannot process input text or expose
attributes. It's just a dumb tree. It's the job of rule::operator= to
turn it into a Spirit parser. To do that, it must walk the tree and
manipulate it, and to do /that/, it places certain constraints on the
compile-time structure of the tree: that it satisfies a grammar. It is
THAT constraint that I'm trying to model.

> 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.

This is the crux of it, thanks. I need OR-constraints. Concepts don't
have 'em.

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