Re: Late review of Boost.Parser

From: David Sankel (camior_at_[hidden])
Date: 2024-03-01 17:38:35

On Fri, Mar 1, 2024 at 12:04 PM Christian Mazakas via Boost <
boost_at_[hidden]> wrote:

> > Parser combinator libraries have progressed a lot since then and, having
> > used both styles extensively, I'm much more eager to pick up one of the
> > more modern designs.  I would expect a Boost library to reflect the state
> > of the art not only in language features used, but also in API design for
> > the domain.
>
> Do you have any C++ examples where this is the state of the art?

Google monadic parser combinator C++ and you'll find plenty.

> Do you
> have any examples of current literature?
>

I'd suggest starting with the 2001 parsec paper and looking to where it was
cited by later research on scholar.google.com.

> Declaring monadic parser combinators to be the state of the art when
> Haskell is
> mostly relegated to academic programs is kind of ostentatious, for lack of
> a better term.
>

Seriously? Industry languages borrow state of the art from research
languages all the time.

The thing about Haskell is that it's had time to gain ground but it just
> hasn't
> because people aren't interested in it.

This isn't relevant.

> I don't mind exploring the design
> space
> of transforming parsers but I don't think there's anything particularly
> outdated
> about Parser's approach.
>

Great, that's exactly what I'm encouraging. Explore the design space!

> If anything, I think the way you compose parser_interfaces in this library
> actually
> would be the natural transformation required to form the monad in the first
> place.
>

Which aspects of "the way you compose" form the monad?