Hi Louis, On 2015-06-03 23:42, Louis Dionne wrote:
Louis Dionne
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