Re: Interest in new parsing library?

From: Zach Laine (whatwasthataddress_at_[hidden])
Date: 2023-12-29 20:55:54

On Fri, Dec 29, 2023 at 12:40 PM Zach Laine
<whatwasthataddress_at_[hidden]> wrote:
>
> On Fri, Dec 29, 2023 at 3:53 AM Andrzej Krzemienski <akrzemi1_at_[hidden]> wrote:
> >
> >
> >
> > czw., 28 gru 2023 o 22:05 Zach Laine via Boost <boost_at_[hidden]> napisał(a):
> >>
> >> I'm trying to gauge interest in a parsing library to replace
> >> Boost.Spirit 2/Spirit X3.  I'm also looking for endorsements.
> >>
> [snip]
> >
> > Hi Zach,
> > Thank you for writing and sharing this library. I intend to test it on my mini-language early next year.
>
> That sounds useful.  Please let me know how it goes.
>
> > For now, let me dig a bit about the high-level differences between Boost.Parser and Boost.SpiritX3.
> >
> > Your introduction mentions "a separate lexer" as a feature that Boost.Spirit is missing.
> > How does that square with the entire section for Spirit.Lex in Boost.Spirit docs?
>
> No, I meant the other way around.  *Boost.Parser* is missing that.
> Sorry for the confusion.
>
> > "Boost.Parser aims to be a superset of Boost.Spirit". But Boost.Spirit is also a generator.
>
> Quite right!  I forgot about that; this is another thing that
> Boost.Parser is missing vs. Spirit.
>
> > You mention that "Spirit X3 has rules that do not compose well". I personally never experienced this. Is there an example somewhere that would illustrate this problem?
>
> The issue for me is that the attribute types generated by X3 parsers
> and rules are loose.  This is by design.  So, say you have a parser
> that parses strings, producing a range of char:
>
> auto p = /* ... */;
>
> If you then use p to parse into some std::string variable in the
> middle of the parse, everything works as you'd expect.  But if you use
> p to parse into a different std::vector<char> variable in the middle
> of the parse, that also works.  This is not by itself a problem.
> However, I had a problem with this semantic, because there was no way
> to lock down the attribute type to a specific, concrete type.  So if
> at some point in the parse I had:
>
> auto p_p = p >> p;
>
> That may be used to generate a std::variant<std::string,
> std::vector<char>>, a std::variant<std::vector<char>, std::string>>,
> etc.  These types are not interconvertible.  So, If you made a mistake
> somewhere in writing a semantic action or something, you get an error
> stating that std::variant<std::string, std::vector<char>> is not
> assignable to std::variant<std::vector<char>, std::string>> or
> whatever, and figuring out where the error actually lies is very
> difficult.  If you have a Boost.Parser rule, it has a concrete
> attribute type A, and so it always produces As.  I find this much,
> much easier to diagnose and debug when I make a mistake.
>
> > What is the recommendation of Boost.Spirit authors to the programmers that need to do parsing? Is Boost.Parser simply the newer and improved version, or do they have disjoint sets of use cases?
>
> I think Joel answered that above.
>
> > Personally, skimming through the docs, I find the feature of producing custom error and warning messages very attractive. This is what I was always missing from the parsing libraries.
> >
> > Thanks again for your effort.
>
> Thanks for taking a look!  Also, I should mention that this is the
> easiest library I have ever written, given its complexity.  That is
> true due to all the very nice design work that came before it, from
> Joel, Hartmut, and others.
>
> Zach

I somehow sent only this one reply to Andrzej only; echoing here.
Sorry for the borked formatting.

Zach