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: Louis Dionne (ldionne.2_at_[hidden])
Date: 2015-06-03 17:42:23

Louis Dionne <ldionne.2 <at> gmail.com> writes:

> [...]
> >
> I am currently going through Metaparse's tutorial, and here are some questions
> and comments I have so far. I will be posting more questions by replying to
> this message if some come up as I progress through the tutorial. I will
> provide a proper review of the library when I'm done.

Abel, I have a few more comments and questions.

3. First, a non-technical point about the tutorial.
   I will reiterate my position about the format of the tutorial being slightly
   inadequate. I was around the end of the tutorial and I wanted to copy/paste
   everything we had so far so I could play with it. To do this, I had to
   copy/paste bits of solutions going up to the beginning of the tutorial.
   All in all, it took me about 15 minutes to put the right bits together and
   to get the final example compiling in a single file on my machine. The
   format of the tutorial is 100% incremental, but my reality when reading a
   tutorial is that I go to it and then come back, and I expect the milestones
   to be larger-grained than what Metaparse provides.

   I think a solution that would address 90% of my complaint would be to
   provide "what we got so far" code blocks on important milestones. That
   way, one could simply copy/paste the whole code block and get started
   right away. Other than this, I like the way you introduce concepts and
   I never felt lost reading the tutorial. Good job on the redaction.

4. I would like to see metaparse provide a master header including everything
   else (like `boost/metaparse.hpp`). I don't mean that such a header is
   terribly useful when actually coding, because you'll never want to pull
   the whole thing in production code. However, it makes the process of
   learning and hacking stuff around so much easier, cause you just have to
   #include the whole thing and get started. Since being easily teachable and
   hackable is an important feature of a library, I think a master header
   would be valuable. Also, it is a trivial change.

5. I would like to see charts showing compilation times in relation to the
   complexity of the parser as well as the length of the input. For example,
   I would like to see how the simple calculator example behaves at
   compile-time for different input sizes, and how the one with error
   handling does, and so on. However, since I know it's a total pain in the
   ass to set this up oneself (I did it for MPL11 and Hana), I could set it
   up for you, show you how to write the benchmarks with my framework and
   then you would do the rest of the work yourself. To make this more
   concrete, here's what I have been able to generate in about 10 minutes
   of work. It is a benchmark of the final parser we end up with (with error
   handling and all) for different sizes of input:
        http://postimg.org/image/buuz4988b/
   I must agree this is not conclusive at all, but like I said I hacked it
   out in 10 minutes and I don't know the internals of the library.

6. While doing the above benchmarks, Metaparse threw up with strings of about
   37 characters long. I believe this limitation has something to do with how
   the MPLLIBS_STRING macro is implemented. However, there are other
   alternatives to this macro when C++11 is available. See for example
   how I do it in Hana here: https://goo.gl/9dxVtx
   There's also a GNU extension supported by both Clang and GCC which allows
   compile-time strings to be defined using a user-defined literal. You can
   also see how Hana uses it through the above link. I think it would be a
   very, very valuable addition to the library to support longer strings via
   those techniques when the compiler supports it.

Regards,
Louis