Re: [boost] [metaparse] Review period starts May 25th and ends June 7th - ongoing

Subject: Re: [boost] [metaparse] Review period starts May 25th and ends June 7th - ongoing
From: Lee Clagett (forum_at_[hidden])
Date: 2015-06-07 22:34:44

On Thu, May 28, 2015 at 9:12 AM, Christophe Henry <
christophe.j.henry_at_[hidden]> wrote:

> Dear all,
>
> The review of the metaparse library started last Monday.
> Please consider taking the time to review it and post comments or reviews
> on this list.
>
> Thanks,
>
> Christophe
>

[snip]

>
> Everybody on this list is invited to participate in this formal
> review. I hope to see your review of Metaparse, including your vote on
> acceptance, and I welcome your participation in the ensuing discussions
> on the Boost developers' mailing list.
>
> Please always include in your review a vote as to whether the library
> should be accepted into Boost.
>

Yes.

> Additionally please consider giving feedback on the following general
> topics:
>
> - What is your evaluation of the design?
>

I don't have much negative to say about the design, because the
functionality is similar to mpl, which I am also familar with. I like the
consistency of the interface(s). As others have noted, it would be
interesting to try the newer style of TMP (dependent typing), because
syntax similar to Spirit might be possible. Requiring an internal `::type`
for result types also surprised me (also previously noted). The only other
point is a nitpick (again, previously mentioned) - the `any` parser is
surprisingly repetitive and not an alternation.

- What is your evaluation of the implementation?
>

I looked at some of the implementation (I was curious). The parts I saw
seemed well-written. Some thoughts:

* Adding support for the Gcc character-literal expansion extension would be
nice, because the strings macro has some intense pre-processor work.
* Compiling in C++11 mode is noticeably quicker for some of the examples I
tried (in clang and gcc) - due to the true variadic string implementation
(no pre-processor)?
** I noticed some of the other areas used pre-processor variadics (one_of,
etc.), could C++11 variadics improve compilation time here?
** Using boost::mpl::vector for sequences/repeats feels ancient, could this
be moved to a mpl conformant C++11 variadic implementation too? mpl has
pre-processed headers, but still have lots of symbols/code for the compiler
to parse and manage for the variations. Since the documentation states that
the repetition/sequence based parsers return a "implementation-defined" mpl
sequence, could this data structure be swapped in c++11 mode? Unfortunately
I can't find a compile-time performance comparison of mpl::vector and a
similar data structure using C++11 variadics.

- What is your evaluation of the documentation?
>

I find the documentation suitable, but I also skimmed the tutorial and went
to the libray reference instead. After looking at a few examples, I started
"hacking" at it. The diagrams in the documentation were also nice.

- What is your evaluation of the potential usefulness of the library?
> - Did you try to use the library?
>   - With what compiler?
>

Yes. With gcc 4.8 and clang 3.5. I have a partially implemented a printf
format string to spirit::karma expression tree conversion utility that uses
metaparse. The library worked exactly as expected everytime, the
difficulties were mainly in the complexities of the printf specification.

  - Did you have any problems?
>

The compile-times I experienced were not great. A decent portion may have
been due to the usage of spirit, another library known to have significant
compile times. The (somewhat) simple calculator example still takes ~2.5s
to compile in clang 3.5 C++11 mode. This was on an older laptop, maybe I
should just upgrade. Although it would be nice to see if there are ways to
improve on the compilation time - otherwise people might avoid this
library. The framework that Louis mentioned previously seems worthwhile.

- How much effort did you put into your evaluation? A glance? A quick
> reading? In-depth study?
>

A decent amount of effort considering how much of the library I used for my
printf->spirit utility. A little less on the tutorial and getting started
part of the documentation.

- Are you knowledgeable about the problem domain?
>

I'm fairly knowledgable of TMP techniques, but new to compile-time parsing.
Its difficult for me to say whether a better solution exists for this
specific problem.

Lee