work with any MonadIO fixing #104

[KommuSoft]

Fixing #104

[jgm]

@tarleb what do you think of this change?

One query. Instead of

 class ToJSONFilter m a where
   toJSONFilter :: a -> m ()

would it make sense to do

class ToJSONFilter a where
  toJSONFilter :: forall m. MonadIO m => a -> m ()

? (I suppose maybe the former is more flexible, as it allows one to define instances for non MonadIO monads, and even non-monad functors.)

[jgm]

Do we still need this? After all, IO is an instance of MonadIO, so this is already covered by lines 111-115, isn't it?
Ditto for the other IO instance below.

[tarleb]

I guess I'd prefer the forall version over the multiparam typeclass, but I don't feel strongly about it.

[jgm]

Is there any particular reason favoring the forall approach?

[tarleb]

I left out my reasoning intentionally, as I don't have a good answer for that. The universally quantified variant seems cleaner and more focused to me. The extra flexibility that comes with the multiparam typeclass variant probably won't be necessary for most users.

[jgm]

I think most users won't touch this at all, or even know about it.

Seems to me that non-MonadIO instances are conceivable -- e.g. for Conduit or pipes or any streaming abstraction that can receive input and give output.

[KommuSoft]

The original reason to do this was to also work for example with a StateT IO Int Pandoc, and thus can use this when working with the toJsonFilter (walkM someFunc) with someFunc :: Pandoc -> StateT IO Int Pandoc for example. We can work with evalStateT 0 (walkM someFunc) and use that with toJsonFilter, but that requires to initialize the state before the walkM and the state is "gone" after the walkM then. It would be nice if toJsonFilter could thus work with StateT IO Int Pandoc as well, to process this. The forall will likely not allow that, since it means it can convert it to any MonadIO.

[jgm]

It should work fine either way with StateT IO Int Pandoc -- something that works for all MonadIO instances will work for this one.

[KommuSoft]

Yes, but if someFunc thus is an Pandoc -> StateT IO Int Pandoc, then the toJsonFilter needs to be able to handle this, with the current implementation, it only handles a Pandoc -> Pandoc or a Pandoc -> IO Pandoc.

[jgm]

Maybe I'm misunderstanding. If we have

class ToJSONFilter a where
  toJSONFilter :: forall m. MonadIO m => a -> m ()

Then toJSONFilter could indeed be applied to someFunc which has type Pandoc -> StateT IO Int (), which is an instance of forall m. MonadIO m => a -> m(). It could not be applied to Pandoc -> StateT IO Pandoc, but neither could your interface

 class ToJSONFilter m a where
   toJSONFilter :: a -> m ()

because () doesn't match Pandoc.

[jgm]

I'm going to merge this and remove the unnecessary IO instance in a second commit.