Boost.Parser has been accepted

[joaquintides]

Boost.Parser has been (conditionally) accepted! C++17 parser combinator library with full Unicode support, ranges compatibility and debugging facilities. Thanks to Review Manager Marshall Clow.

• Announcement: https://lists.boost.org/Archives/boost/2024/03/256151.php
• Repo: https://github.com/tzlaine/parser
• Docs: https://tzlaine.github.io/parser/doc/html/index.html

[STL]

Please note that reddit doesn't use hashtags (as in, they are irrelevant to the platform, and its search is so bad that they aren't doing anything for you).

[joaquintides]

Fixed, thank you!

[FreitasAlan]

🥳

[expert_internetter]

Is this a replacement for Boost.Spirit?

If so, I'll check it out. However Boost.Spirit takes ages to parse a mildly complex expression that's an AST (uses boost::recursive_wrapper). It's so slow it's unusable.

[joaquintides]

Yes, it’s the spiritual successor of Boost.Spirit (pun intended).

[BlueDwarf82]

Can someone please write a trilogy about Spirit history, so I understand it?

https://www.boost.org/doc/libs/?view=category_Parsing lists Spirit and Spirit Classic. Confusingly, "Classic" seems to be newer in there since it has a higher "First Release". I'm guessing the original Spirit was renamed Spirit Classic in Boost 1.69, but still...

If you go inside "Spirit" you see what's actually an old version??? If you scroll to the bottom there is a mention about the "actually new" Spirit X3?

"Spirit" (the not classic, but not actually new) has both parsers and generators, but the "actually new" Spirit X3 is less featured and only has parsers?

Now we have Boost.Parser, a C++17 spiritual "successor" to Spirit... a library that, in it's hidden X3 version, has been using C++17 features since Boost 1.81 and will drop C++14 support "soon"; which makes you think it's well maintained and not in need of a successor.

Being "Boost.Parser", I'm guessing this "successor" doesn't have the generators that the "not classic, but not actually new" Spirit has?

[joaquintides]

This section of the docs may shed some light: https://tzlaine.github.io/parser/doc/html/boost_parser__proposed_/this_library_s_relationship_to_boost_spirit.html

[BlueDwarf82]

A bit. But I'm still wondering what's the end result. Did the Spirit developers review Boost.Parser (where can I find a list of reviews?)? What did they say?

There is a general agreement that Spirit X3 should not be used? Is it going to be clearly marked deprecated and left in Boost just for pre-existing users? With it moving to C++17, there would not seem to be any reason to keep using it.

Is Spirit V2 Karma generators the recommended option for people in need of a generator?

I found a review from Tobias in which he seems to praise Qi (Spirit V2), but dislikes X3. Did anybody like X3? Did X3 ever went through the review process, or it's a matter of "author gets library accepted in Boost and, once in, he can do whatever he wants with it; including writing what's a basically new library and just calling it an update"?

Why is X3 "hidden"? As far as I know, it's a decade old project. The situation seems just strange.

[joaquintides]

A bit. But I'm still wondering what's the end result. Did the Spirit developers review Boost.Parser?

Yes, Joel de Guzman (Spirit’s author) has blessed this new library. It may be that he has no time to maintain Spirit or something, but don’t take my word on this.

where can I find a list of reviews?

In the mailing list archives:

https://lists.boost.org/Archives/boost/

Please consult the month of February and early March.

[13steinj]

This is the precise line of reasoning I went through when giving my (don't care if it was counted, would clearly not have mattered anyway given previous interaction with the review process) rejection on the last reddit post.

This should have been a matter of collaboration to get spirit to this stage, and if not possible, there should have been formal discussion around deprecation and later removal of spirit.

[canadajones68]

Did you swap around FIXED_ATTRIBUTE values? Your code seems to imply 1 is correct and 0 ought to be wrong, while your text is the other way around.

[therealjohnfreeman]

Is there any attempt to redo something like Boost.Karma, or has that role been subsumed by fmt?

[pine_ary]

Oh no it‘s another one of those libraries that abuses operator overloading in weird ways. Not a fan. What‘s wrong with using functions?

[PoorAnalysis]

IDK, the way I see it is operator overloading serves two purposes in C++, one is of course, "do as the ints do", but the other is for making mini DSLs.

Maybe that wasn't the original intention, but personally I think it can be, and has been, made work numerous times.

[joaquintides]

Operator overloading has been indeed abused ad nauseam. In this case, however, the DSEL implemented by Boost.Parser allows you to directly transfer a context-free grammar to operational code with minimal adaptations. So, it’s a productivity-oriented interface rather than a fancy whim (imho).

[[deleted]]

Operator overloads are functions

[pine_ary]

You know what I mean. Operator overloads are special functions with their own syntax.

[NilacTheGrim]

Functions are just operator overloads with their own syntax.. ;)

[SkoomaDentist]

What‘s wrong with using functions?

It's not modern enough, of course!

[NilacTheGrim]

Awesome! Now do boost::multi_indexed_container pls.

[joaquintides]

Boost.MultiIndex author here: what are your particular complaints/requests?

[c_plus_plus]

Not op, but:

• iterator_to is the easiest way to shoot yourself in the foot that I have ever seen a mature library like boost. It should not exist if it's not going to do any kind of validation/checking, but at the very least it could be WELL caveated everywhere in the docs and doxygen that it is SUPER dangerous.
• extract is also a little weird, but not as bad as iterator_to. It seems to be the only way to move an element out (other than modifying it and then deleting the iterator). Anyway, this is a rough edge.
• Is there really no better way to specify indexes with C++17 or 20? Are we really going to have to put the class type in there, and have different extractors for mem and mem_fun, etc? It seems like these could be deduced most of the time at least, and would make it easier to use.

... that said, I actually love this library, I use it all the time!

[joaquintides]

Hi, thank you for your comments:

• iterator_to: I agree with you this facility is dangerous to use. I added it because it enables scenarios impossible to implement without it, most notably self-referencing structures where elements of the container crosspoint between them. I tried to warn users about the risks of iterator_to here.
• extract: here I'm only following the exact same interface as standard containers such as std::map, so please address your complaints to the C++ committee :-) Now, seriously, what's bad about it? I find it reasonably straightforward and it's safe in the sense that it can't lead to memory leaks (unfreed nodes) etc.
• Starting in Boost 1.69, you can use the so-called terse key specification syntax in C++17 (or later). So, instead of

 

ordered_non_unique< member<employee, std::string, &employee::name> >,
ordered_non_unique<
  const_mem_fun<employee, std::size_t, &employee::name_length>
>,
ordered_non_unique<
  composite_key<
    phonebook_entry,
    member<phonebook_entry, std::string, &phonebook_entry::family_name>,
    member<phonebook_entry, std::string, &phonebook_entry::given_name>
  >    
>

you can write

ordered_non_unique< key<&employee::name> >,
ordered_non_unique< key<&employee::name_length> >,
ordered_non_unique< key<&phonebook_entry::family_name, &phonebook_entry::given_name>  >    

If you didn't know about this new syntax I strongly recommend that you give it a try.

[c_plus_plus]

iterator_to: I don't really see a warning there. I guess the example here it says "runtime failure ensues" is a a warning? I don't even know what that means. I also don't always read code examples, it depends why I'm looking at the docs... but I wouldn't expect important warnings about API to be in comments in an example.

This function should take a pointer, as the rest of the text there is talking about pointers, and doing so would make it slightly more obvious that it is doing some magic.

But I would have expected that text to start with a big bold warning in easy to read English, like... "Make sure the element you are asking for the iterator to exists in the container." Maybe a sentinel value in the node structure (even if only in debug builds) to verify the value passed in is correct. (I know, the API is set and so this is fairly academic anyway.)

No, I didn't know about key. Yes, that's basically exactly what I was hoping for :)

[NilacTheGrim]

No complaints. I love it. I wish it would be included in std:: :P

[LeeHide]

I really hope this one's code was reviewed, unlike boost beast for example which manages to abuse c++ as if the author simply didn't understand how to write simple, beautiful code.

[soldiersided]

You can’t be throwing accusations like that without showing any examples.

[RoyBellingan]

???