5 Jul 03:35
Re: [proto] grammar compile error
Eric Niebler <eric <at> boostpro.com>
2009-07-05 01:35:41 GMT
2009-07-05 01:35:41 GMT
Felipe Magno de Almeida wrote: > On Sat, Jul 4, 2009 at 2:29 PM, Eric Niebler<eric <at> boostpro.com> > 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RSS Feed