Late review of Boost.Parser

From: David Sankel (camior_at_[hidden])
Date: 2024-02-29 22:43:40

# Are you knowledgeable about the problem domain?

Yes. I've written several parser combinator libraries in C++ and used still
more in C++ (Spirit v1, v2, and qi) and other programming
langauges (Haskell's Parsec, attoparsec, and others).

# How much effort did you put into your evaluation? A glance? A quick
reading? In-depth study?

I read through the tutorial documentation and some of the reference
documentation. I also tried to create several examples with the library and
made comparisons to Haskell's Parsec.

# What is your evaluation of the potential usefulness of the library?

Very

# What is your evaluation of the documentation?

The documentation isn't great. Consider char_
<https://tzlaine.github.io/parser/doc/html/boost/parser/char_.html>'s
documentation. It includes no examples and fails to mention it can be used
without arguments.

It seems strange that the tutorial focuses so much on semantic actions. It
seems like the more common case would be to parse into some kind of
abstract syntax tree.

# What is your evaluation of the design?

Much of the wealth of research into parser combinators wasn't incorporated
into this library. I didn't see in the documentation, for example, an easy
way to "map" one parser's attribute into another. This kind of thing should
be a basis operation provided by the library.

# What is your evaluation of the implementation?

The usage of has_include is a ODR nightmare for large codebases. It would
be better to generate some kind of config.hpp that sets these definitions
at compile time.

For custom variant/tuple types, user specialization of variable templates
is also an ODR nightmare. Again, a config.hpp would be better for this. For
this, though, I don't think the configurability is worth the complexity. We
have standard types for these so we should use them.

# Did you try to use the library? With what compiler? Did you have any
problems?

Yes, I tried to use the library with a modern compiler on a MacOS machine.
I didn't have any problems building.

# Do you think the library should be accepted as a Boost library?

No, I do not think it should be accepted.

Overall, I think the syntax has too much focus on magically filling in
user-provided structures instead of the basics of monadic parser
combinators and basis operations. Consider the following Haskell parser
which evaluates simple parenthesized sum expressions. I wasn't able to use
Boost.Parser to accomplish this after reading the documentation and several
attempts. I'm sure it's possible, but I don't see how it can be done using
the combiners and primitives provided.

import Text.Parsec.String (Parser)import Text.Parsec
integer :: Parser Integerinteger = do
  n <- many1 digit
  return (read n)
integerPlus :: Parser IntegerintegerPlus = do
  x <- integer
  y <- (try $ char '+' >> expression) <|> return 0
  return $ x+y
parentheses :: Parser Integerparentheses = do
  char '('
  x <- expression
  char ')'
  return x
expression :: Parser Integerexpression = integerPlus <|> parentheses