2015-06-03 21:44 GMT+02:00 Abel Sinkovics :

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

2015-06-03 22:55 GMT+02:00 Abel Sinkovics :

Hi Andrzej,

On 2015-06-03 22:32, Andrzej Krzemienski wrote:

...

2015-06-03 21:44 GMT+02:00 Abel Sinkovics :

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.

If I understand you correctly, some example from which one can "easily" tell what the library is about would make sense in the documentation (probably on the first page).

For optional it is easy, as its scope is small and the concept is well known. For a compile-time parser generator library it is more difficult to come up with such an example,

Agreed. It may be that this is a problem domain that makes the docs more difficult.

but I'll try my best.

How a bout writing a string literal for boost::rational<int>. It uses only raw floating-poit literals, accepts forms without exponent, forms the nominator and denumerator and turns them into boost::rational<int>. Would that take long? Regards, &rzej