Re: [boost] [proto] grammar compile error

Subject: Re: [boost] [proto] grammar compile error
From: Eric Niebler (eric_at_[hidden])
Date: 2009-07-04 21:35:41

Felipe Magno de Almeida wrote:
> On Sat, Jul 4, 2009 at 2:29 PM, Eric Niebler<eric_at_[hidden]>
> wrote:
>> There is really only one good reason to specify a grammar when
>> defining a domain, and that is to disable troublesome operator
>> overloads. My suggestion would be to not specify your dsel's
>> grammar up front, but rather only validate full expressions at the
>> point of evaluation. You lose no safety that way.
> 
> Defining a grammar loosely is harder than specifying it fully. Doing
> it fully, all I need to do is: shift(create, table, table_name, 
> columns) and I'm done.

Agreed.

> But if I do it for all partial expressions, I might forget something.
>  I'm trying to define a SQL grammar. Having it checked earlier, helps
>  me traversing it later, since I know it is right.

I don't see it. You also know it's right if you check the full
expression against your full grammar before you traverse the expression.

> Also, it prohibits most expressions right away, giving better error
> messages.

This is not true. "Checking early" means dropping operator overloads via
SFINAE, leading to error messages like "no operator << matches with
arguments [complicated type 1] and [complicated type 2]" followed by a
so-called candidate list, the list of every operator overload that
didn't match. This is usually a huge and impenetrable error.

But if you do a late check against the full expression with
BOOST_MPL_ASSERT and proto::matches, the error is much shorter and takes
users directly to a line of code that looks like this:

   BOOST_MPL_ASSERT((proto::matches< SqlExpression, SqlGrammar >));

That makes the error much more understandable.

> I wouldn't have to check later on if there's a non-sensical terminal
> anywhere.
> 
> create << table << create would have no overloads.
> 
> All I need is to traverse a grammar, and define another grammar with 
> all sub-expressions. Since the grammar is not very big, it shouldn't
> be too hard on the compiler (I hope). Though I'm not very experienced
> with proto yet.
> 
> Is transforming a grammar a really difficult task?

You're setting yourself up to climb a mountain, and I don't think you'll
like the view from the top.

My $0.02,

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