9.4 migration: getSourcePos now requires `Monad m =>` about megaparsec HOT 6 CLOSED

This change was introduced in #514. In short, now MonadParsec e s (ParsecT e s m) instance requires Monad m, which was always assumed since it is the inner monad in the monad transformer, but now it has to be included in the constraints because of the new method mkParsecT which uses the bind of the inner monad m.

from megaparsec.

I'm curious how did it work before

All methods of MonadParsec worked directly by calling continuations and did not rely on m being a monad, i.e. they did not use monadic bind on m.

is the change necessary

Actually given that mkParsec does not make use of m (unlike mkParsecT) I think the constraint could have been avoided. I just did not think it would be problematic. I could try to remove it if it poses a problem for you.

from megaparsec.

See #533.

from megaparsec.

Thanks Mark. In hledger at least it's quite impactful, it will require changing ("cluttering" ?) 140 type signatures, so I wanted to check it's intended before doing that. I don't know if I'm an outlier here. If it stays, it should probably be added to the changelog. (I didn't find/recognise the responsible change by comparing haddocks either.)

from megaparsec.

Okay, 9.4.1 is on Hackage. It should have the same constraints as in older versions of the library.

from megaparsec.

Thank you very much!

from megaparsec.