9.4 migration: getSourcePos now requires `Monad m =>`
simonmichael opened this issue · 6 comments
Thanks for megaparsec 9.4. I'm testing for commercialhaskell/stackage#7003 , and it seems that a ton of my type signatures now require Monad m =>, because of using getSourcePos (and probably other things). That function's haddock hasn't changed and the changelog doesn't mention this. I'm curious how did it work before, what caused it to change, and is the change necessary ?
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.
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.
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.)
Okay, 9.4.1 is on Hackage. It should have the same constraints as in older versions of the library.
Thank you very much!