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-05-30 01:43:30

Hi Louis,

On 2015-05-29 19:00, Louis Dionne wrote:
> 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.
Thank you for checking it.

> 1. What is the `mpl_` namespace? Is it documented in the tutorial for Metaparse?
>     If it is a shortcut for `boost::mpl`, why the trailing underscore?
It comes from boost::mpl and is not related to Metaparse:

 > #include <boost/mpl/int.hpp>
 > boost::mpl::int_<13>
mpl_::int_<13>

This could be mentioned the first time it pops up in the tutorial.

> 2. I personally am not using Metashell for the tutorial because it does not
>     properly support the '<' and '>' characters on OS X (I think that's a
>     shellinabox bug). As a result, I find it slightly difficult to follow
>     the code blocks in the tutorial because of the newline escapes (`\`)
>     and numbered names (`exp_parser16`) required for the code to be pasteable
>     in Metashell. I would personnally prefer a more classical approach with
>     normal code blocks not expecting the user to follow along in Metashell,
>     but I realize this is a matter of personal taste.
I'm aware of a shellinabox bug related to Firefox. Chromium seems to 
handle it properly on Linux & Windows. Another option is installing 
Metashell locally (all you need are the Boost and the Metaparse headers 
on your header path).

Since the tutorial is about getting the right types as the result of the 
right metafunction calls (in this case the parsers), it is mostly about 
checking if you got the types you expected. You can use other, more 
classical approaches (eg. displaying the types in error messages, 
asserting for type equality, pretty printing the types, etc), but that 
is more involved in each iteration. (They could be probably mentioned in 
the tutorial though).

Multi-line code examples: one option is adding a copy-paste friendly 
version of each code snippet to the tutorial, so the text remains pure 
html (no scripting). Another option is to use some (probably 
javascript-based) library that displays the code readable but also makes 
it easy to copy it. (I tried to avoid this as to the best of my 
knowledge the documentation is expected to be pure html).

Regards,
   Ábel