3 ms·
I realize I misread parent comment functions: always<A>(x: A): Parser<A> thenDependent<A, B>(a: Parser<A>, b: A -> Parser<B>): Parser<(A, B)> as: alway
by chombier 9y ago
I realize I misread parent comment functions:
always<A>(x: A): Parser<A>
thenDependent<A, B>(a: Parser<A>, b: A -> Parser<B>): Parser<(A, B)>
as:
always<A>(x: A): Parser<A>
thenDependent<A, B>(a: Parser<A>, b: A -> Parser<B>): Parser<B>
which would make a monad provided the monad laws are satisfied.
Of course you don't have to write parser combinators that way, but I found it pretty practical compared to dealing with nested tuples for the sequence parser. Check out Hutton and Meijer's article for more details.
- Tarean 9y agoThe problem with monadic parsers is that they are too powerful. If you have two options string "foo" <|> string "for" It would be nice to automatically rewrite this as string "fo" >> (char 'o' <|> char 'r') But if we try to analyze monadic parsers like that we run into the halting problem. Applicative parsers are less powerful so we can left factor them automatically. There were some attempts to combine applicative and monadic parsers which resulted in arrow syntax but that kind of feels like the worst of both worlds for many cases.