pToken :: Parser

  pExpr :: Parser, Expr>

If it's a List, wouldn't you be forced to write the Cartesian product of two parsers instead?

If pDigit saw "123 ", according to TFA's design, it would return (1, "23 ").

If PInt saw the "123 ", it would return (123, " ").

You could approximate pInt in terms of pDigit via:

  PInt = many1 pDigit

I say "according to TFA's design" because I've been arguing elsewhere that parsers must return Either not (T, Remainder)

You could take a step back and make sure T has a fail case, e.g. T-extends-Either, but what is to be gained?

* Firstly, what the hell is A?

* The user would need to type Parsers of T=Cat and T=Dog instead as Parsers of T=Either and T=Either. If everyone has to do it, pull the common abstraction back into the library itself! Also the caller would receive a successful parse of T=Either and would then need to check to see if it was success(success) or success(fail).

* You also mix abstractions in the same way as newlines in string literals. You could no longer represent a successful parse of a failed Either, since the failed Either would look like a parse error.

The article used it as in a sub-parser, which is the other thing I objected to. If you add two Integers, you get back an Integer, not a Sum. Same principle here, two parsers make a parser. You don't need to write new code to combine a partial parser with a parser, or vice versa.

  type Parser = (input: string) => [T, string]

The article also starts with the concept of a 'partial parser', from which other (non-partial?) parsers can be constructed?

  Or, and this is where the real power of partial parsers comes in: we wrap the chain up as a new parser of its own.

(Ironically there is a fitting definition of 'partial' here: the function isn't well defined on all inputs. For some inputs, T is returned, on other inputs, maybe an error is thrown, who knows..)

I could see the keywords right there in the chat, enter them into the search bar, and get back 'no results found'.

(This was across at least a period of months too, not just an intermittent bug)

You don't need List to write an IntList, nor do you need + to work on different integers in order to have a particular integer.

  I have ordered a complete siege on the Gaza Strip. There will be no electricity, no food, no fuel, everything is closed. We are fighting human animals and we are acting accordingly.

  Cited in Defense minister announces ‘complete siege’ of Gaza: No power, food or fuel, The Times of Israel (9 October 2023).

This is what tests are for. There should be no buildup of internal state that can't be arrived at with a simple invocation in a unit test.

What expectations do you have of the value?

Trees being incompatible with precedence is like parentheses being incompatible with precedence.

I had a look at the link. The BNF looked good:

  Expr =
    Expr '+' Expr
    ...

  Expr =
    Factor
  | Expr '+' Factor
  ...

  fn expr_bp(lexer: &mut Lexer, min_bp: u8) -> S { 
    let mut lhs = match lexer.next() {
        Token::Atom(it) => S::Atom(it),
        t => panic!("bad token: {:?}", t),
    };

    loop {
        let op = match lexer.peek() {
            Token::Eof => break,
            Token::Op(op) => op,
            t => panic!("bad token: {:?}", t),
        };
    ...