Re: [boost] [metaparse] review

Subject: Re: [boost] [metaparse] review
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2015-06-03 16:32:26

2015-06-03 21:44 GMT+02:00 Abel Sinkovics <abel_at_[hidden]>:

> Hi Andrzej,
>
> Thank you for the review.
>
> On 2015-06-03 17:07, Andrzej Krzemienski wrote:
>
>> I see use cases for each of these components separately. Parsing templates
>> with characters, is painstaking but fairly easy, so I may want to do it
>> myself, provided I have a way to convert a string literal to a template. I
>> was trying to hack it for a long while, without success. There is quite a
>> bit of trickery put into it. It is really ingenious.
>>
> To parse very simple languages, it usually does not worth the effort to
> use a parser generator library. But as the language gets more complicated,
> tools like a parser generator library seem to offer more and more.
>
> Also note that a lot of effort is gone into producing useful error
> messages for invalid inputs (when your parser finds errors in the parsed
> text) in Metaparse. (See section "11. Dealing with invalid input" in the
> tutorial). There are cases (like missing closing parens) where the library
> can provide good error messages (eg. where the unclosed opening paren is)
> without the parser author having to put extra effort into it.
>
>  On the other hand, when processing my raw user-defined literals, I may
>> need
>> your parsers, but I care not about BOOST_MS_STRING() (or how you want to
>> call it).
>>
> The library works with any character container that supports mpl::front
> and mpl::pop_front. So you can either instantiate the string<> template
> with your characters or can use your own container.
>
>  - What is your evaluation of the documentation?
>>>
>> Well, after having read it, I understood what to expect of it, so in that
>> sense, it is adequate. But there is something about it that makes it
>> "heavy". Maybe it is just the problem domain, I do not know.
>>
> What do you mean by "heavy"?
>

I am not quite sure either. Sorry, if I am being imprecise. For instance, I
am rather impatient (and I suspect I am not the only one),  and expect that
I will learn from the documentation in less than three minutes, what is its
scope, what I will and will not able to do with it, and how using it will
look like. In the metaparse doc, I was not able to do that, I was forced to
read the tutorial, whose pace is too slow for me. I got impatient and
distracted.

My remark is not to the amount of information, but to how it is ordered.
For instance, when you look at the documentation of Optional (
http://www.boost.org/doc/libs/1_58_0/libs/optional/doc/html/index.html), in
the first page you get a short example of how it is used and why you want
to use it. The potential user can immediately make a decision whether she
wants this library or not.

I hope I am making sense. I cannot describe it any better. Perhaps it is
just personal preference.

BTW, nor I recall one thing, I failed to bring up earlier. There parser for
detecting repeated elements is called "any". This name seams inadequate.
Perhaps "any_number_of_times" or "repeated" would indicate the intent more
clearly?

Regards,
&rzej