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: Abel Sinkovics (abel_at_[hidden])
Date: 2015-06-03 18:06:32

Hi Louis,

On 2015-06-03 23:42, Louis Dionne wrote:
> Louis Dionne <ldionne.2 <at> gmail.com> writes:
>
> 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.
The "getting_started" example consists of headers that are milestones 
for the tutorial. For example to get all the definitions before section 
5.2.1, you should include "5_2_1.hpp". This is mentioned at the 
beginning ("1.1 Testing environment") of the tutorial. Is that what you 
meant?

> 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.
It is doable (actually, such master header already exists, but not as 
part of the library, but as part of the tests - all_headers.hpp). I'm 
happy to add it, but probably in a way to generate a warning from it.

> 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.
I did that for regular expressions and printf. See:

http://abel.sinkovics.hu/download.php?fn=dsltemp.pdf, section 5.3 (printf)
http://abel.sinkovics.hu/download.php?fn=dsltemp.pdf, slide 162 (regex 
and the string macro)

They can (and will) be added to the documentation as well. Error 
handling has not been checked.

If you have some reusable environment, I'd be glad to use it (I've done 
the measurements with ad-hoc scripts).

> 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.
The maximum length of the string can be controlled by the 
MPLLIBS_LIMIT_STRING_SIZE macro (see 
http://abel.web.elte.hu/mpllibs/metaparse/MPLLIBS_STRING.html).

I've tried embedding the string literal in a lambda, but I couldn't 
instantiate a template with the type of the lambda (lambda in an 
unevaluated context).

I haven't checked how to take advantage of non-standard compiler 
extensions where available, but it is a great idea that definitely worth 
investigation.

Regards,
   Ábel