tzlaine / parser

A C++ parser combinator library.

parser

This is a parser combinator library for C++. As a quick example of use, here is a complete program that parses one or more doubles separated by commas, ignoring whitespace:

#include <boost/parser/parser.hpp>

#include <iostream>
#include <string>


namespace bp = boost::parser;

int main()
{
    std::cout << "Enter a list of doubles, separated by commas.  No pressure. ";
    std::string input;
    std::getline(std::cin, input);

    auto const result = bp::parse(
        input, bp::double_ >> *(',' >> bp::double_), bp::ws);

    if (result) {
        std::cout << "Great! It looks like you entered:\n";
        for (double x : *result) {
            std::cout << x << "\n";
        }
    } else {
        std::cout
            << "Good job!  Please proceed to the recovery annex for cake.\n";
    }
}

Features:

• Parsers that parse a variety of things.
• Combining operations that make complex parsers out of simpler ones.
• Multiple ways of getting data out of the parse, including via callbacks.
• Sentinel- and range-friendly.
• Very Unicode friendliness.
• Excellent error reporting, via diagnostics like those produced by GCC and Clang.
• Trace support for debugging your parsers.
• Clever hacks to make compile time errors easier to deal with. (These are totally optional.)

This library targets submission to Boost.

Online docs: https://tzlaine.github.io/parser

Master status:

Develop status:

parser's Issues

Consider adding direct support for UTF-16 string out-attributes

Upgrade the internal Boost.Text to the latest range-based one.

Eliminate one of the copies of `is_detected*` and friends

Get rid of the vestiges of the any-`std::integral`-is-okay convention from the `parse()` API

Currently, parseable means any std::integral of size 1 or 4. We only want to allow character types char, wchar_t (non-MSVC), char8_t, and char32_t.

Making iter/sentinel overloads act as a prefix-parse is too subtle

We should treat iter/sentinel and actual-range overlaods the same, and add a parse API that is a prefix-parse instead of a full-parse.

Symbol tables need better naming than `add()`/`insert()`

These are synonyms across languages for the insert() operation, and they don't convey that one of them (add()) is a permanently-mutating operation, and the other (insert()) is a parse-duration-only mutation.

Add a Unicode whitespace parser with a reasonable set of code points

A unary parser should print its child in parens if the child is n-ary

Test for each individual parser: check success on empty-string input

Investigate using a hana::tuple instead of a hana::map as the parse context

Turns out hana::map contains a std::map!

The attribute of `cp` should be `char32_t`, not `uint32_t`

Template `view` should be called `subrange`, and should be an alias for `std::ranges::subrange` if that is available

An unconditional eps in a repeat parser should be an error

Template parameter constraints for all callable parsers

Test for each individual parser: sentinel support

For out-attr parse() overloads, static_assert that the given parser does not produce a nope

Generation of variants is probably broken if multiple alternatives have the same type

Unverified. If this is the case, this is a fix:

    template<typename... Ts>
    auto to_variant(hana::set<Ts...> const &)
    {
        return std::variant<typename Ts::type...>{};
    }

            auto const types = hana::transform(tuple_of_possible_dupes, [](auto const & x) {
                return hana::type_c<std::remove_cvref_t<decltype(x)>>;
            });
            auto const unique_types = hana::to_set(types);
            return detail::to_variant(unique_types);

Create BOOST_PARSER_ASSERT() macro to switch between runtime and compile time assertions.

Right now, there is an ad hoc system in place, in which a macro is used to conditionally compile a static_assert or a BOOST_ASSERT, and some other places never use the BOOST_ASSERT option. Regularize with a macro that hides the conditional assertion type.

ADL audit

Consider making eps | int_ il-formed

It should be ill-formed because we know that eps matches anything, and so later alternatives will never be executed. It is almost certainly a mistake for the user to write that, and catching it at compile time which a helpful static_assert() will catch bugs. There may be more cases than just eps to consider as well.

The skipper overloads of callback_parse() are broken

The tag type used by the callback mechanism should be the tag itself, not the hana::type-wrapped tag

Reduce dependencies

Eliminate either parser::subrange or parser::detail::test::subrange

Publicize a minimal API from the internal copy of Boost.Text, that can be used by users of Boost.Parse to drive Unicode parsing

The docs assume that Boost.Text made it into Boost before this library is considered. Because it did not, text::as_utf32() is not available to select the Unicode code path.