Re: [boost] [metaparse] review

Subject: Re: [boost] [metaparse] review
From: Abel Sinkovics (abel_at_[hidden])
Date: 2015-06-04 00:56:23

Hi Gordon,

On 2015-06-04 02:10, Gordon Woodhull wrote:
>> It might be a bug. Do you still have the code that produced it?
> Sure. I commented each of the places I had trouble in my gist,
> https://gist.github.com/gordonwoodhull/dcbb332eea06dd3279b9
>
> ... which was only a few places, and very small changes a testament that your library is surprisingly easy to use once you get used to it.
This is great, thanks. I can debug it then.

>>> I couldn't figure this out, so I gave each of my AST nodes a self-referential ::type in the way that mpl::vector has:
>>>
>>> template<typename Tail, typename Head, typename Attrs>
>>> struct edge_decl {
>>>    typedef edge_decl type; //why?
>>> };
>>>
>>> Something is not right here!
>> Note that when I was experimenting with lazy evaluation, then I came to the conclusion that adding such self-referential ::type to every class you intend to use as value in template metaprogramming makes life much easier. You don't need to worry about where you return a value and where you return a thunk.
>>
>> However, this does not change the fact that Metaparse should not use ::type where it is not needed.
> Ah, I hope that is it. I could not figure out what I was supposed to be returning, and felt lousy about adding a ::type just to move on.
Note that types representing data (containers, int_, etc) in MPL and in 
the standard (eg. integral_constant) have this self-recursive ::type as 
well which makes them easy to use in lazy code.

>
>>> the parser will greedily eat the epsilon and have nowhere to go (at least according to my amateur understanding of parsers).
>>>
>>> I gave up here and made the separator mandatory. Again, this is probably not a flaw in the design, but the documentation should describe what kinds of grammars will work, and perhaps give pointers to other resources about disambiguating grammars. Probably there is a different construct which would help here.
>> I'm not sure what error you ended up with in this case.
> This is also commented in the gist.
According to gist it looks like using last_of is fine while using 
sequence is not. And they return different things: last_of returns the 
result of stmt, sequence returns a container with [optional semicolon, 
result of stmt] as elements. (and the code processing the result needs 
to expect the right thing)

Regards,
   Ábel