[WIP] feat(std): replace parser lib with more generic version

[Etherian]

Description

Adds a Parsable interface and a parser combinator library based on it to replace the current one.

Related PRs

Depends on #686.

Similar concept to the Streamlike interface (#737)

Status

In Development

Outstanding design questions:

• How should parser handle errors and custom error types? (It will use its own error type. No customization for now.)
• How to cleanly handle types that don't naturally lend themselves to StateT sequencing (String and Array)? (Most likely a wrapper, like in the current parser.)

To Do

• Get StateT to a run without errors to begin debugging.
• Add useful functions
• Add implementations for standard types
• Add inline documentation
• Add documentation in the book?

Prior art

• Revisiting 'Monadic Parsing in Haskell' and yoctoparsec
• nom
• Megaparsec

Future Possibilities

• Build Parsable on top of Streamlike or otherwise take advantage of their relatedness.
• Indexable -> Parsable?

[Marwes]

I like the basic plan of adding a StreamLike type which Parser can be abstracted over but I think it may be a good a idea to take a step back and go for something a bit simpler first (see other comments). The ZipWith, Lazy etc abstractions over StreamLike are neat, but aren't strictly necessary to for the basic idea to work so I think forcusing on just getting Parser working with StreamLike first will make it easier (and then the rest can be added later).

(Seems I forgot/failed to press submit review on this, sorry for the delay!)

[Marwes]

Would be nice to represent a position as an associated type however that does not work in gluon (yet). Could maybe parameterize StreamLike with a position argument though.

[Etherian]

Ignore std/parser.glu for now. It's still a mess.

But what do you think of the Alternative implementation for Result? I think it makes sense.

[Marwes]

But what do you think of the Alternative implementation for Result? I think it makes sense.

It doesn't seem to compile as is :( . Searched for what Haskell does with its equivalent Either type and there doesn't seem to be a way to construct such as an instance https://stackoverflow.com/questions/44472008/why-is-there-no-alternative-instance-for-either-but-a-semigroup-that-behaves-sim

[Etherian]

Sorry. It didn't compile because I wrote it wrong the first time. Alternative (Result (m e)) seems to work now.

If I understand correctly, the answerer of that question says that Alternative can't be implemented for Either because Haskell doesn't allow you to add constraints to the instantiation that don't exist in the definition (maybe that requires an extension?).

While it is possible to construct a type where e has an instance of Alternative you can't make an instance for Alternative for Either with that e because no such constraint is in the type class definition (something along the lines of: (Alternative e, Applicative (f e)) => Alternative (f e)).

But doing so works just fine in Gluon.