Proposal: instance MonadIO Q

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Proposal: instance MonadIO Q

Ryan Scott
Template Haskell currently has runIO :: IO a -> Q a , which allows you
to run IO actions with a guarantee of IO effects' ordering in a single
splice (but not necessarily the order in which all the Q splices are
run). If runIO is indeed a monad morphism, then there is a law-abiding
MonadIO Q instance that could be added to transformers:

instance MonadIO Q where
  liftIO = runIO

This would be useful for dealing with monad transformer stacks with Q
as the base monad (for an example, see genifunctors
(https://github.com/danr/genifunctors/blob/4677bb57423b1b380ce9b50cc3d765a5c49a957a/Data/Generics/Genifunctors.hs#L47).
The only catch is that transformers would have to depend on
template-haskell. I think this would be okay since no quasiquotation
is involved, but I wanted to hear others' opinions.

Ryan
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: instance MonadIO Q

David Feuer

I'm very much in the "Damn the torpedoes; full speed ahead" camp most of the time, but not here. Transformers is a tiny step up from base. Why would you make it depend on template haskell rather than the other way around?

On Jul 23, 2015 12:17 PM, "Ryan Scott" <[hidden email]> wrote:
Template Haskell currently has runIO :: IO a -> Q a , which allows you
to run IO actions with a guarantee of IO effects' ordering in a single
splice (but not necessarily the order in which all the Q splices are
run). If runIO is indeed a monad morphism, then there is a law-abiding
MonadIO Q instance that could be added to transformers:

instance MonadIO Q where
  liftIO = runIO

This would be useful for dealing with monad transformer stacks with Q
as the base monad (for an example, see genifunctors
(https://github.com/danr/genifunctors/blob/4677bb57423b1b380ce9b50cc3d765a5c49a957a/Data/Generics/Genifunctors.hs#L47).
The only catch is that transformers would have to depend on
template-haskell. I think this would be okay since no quasiquotation
is involved, but I wanted to hear others' opinions.

Ryan
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: instance MonadIO Q

Ryan Scott
In reply to this post by Ryan Scott
> Why would you make it depend on template haskell rather than the other way around?

No particular reason, I'd be fine putting the instance in template-haskell instead if that's more palatable.

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: instance MonadIO Q

David Feuer

I think making transformers depend on *anything* is a non-starter, so yes, go the other way.

On Jul 23, 2015 2:15 PM, "Ryan Scott" <[hidden email]> wrote:
> Why would you make it depend on template haskell rather than the other way around?

No particular reason, I'd be fine putting the instance in template-haskell instead if that's more palatable.

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: instance MonadIO Q

Niklas Hambüchen
In reply to this post by David Feuer
I'd also like to mention that there's a camp of people who'd like to
have a safe/pure version of TH that cannot do any IO - for changes like
the proposed one we should check whether they'd make that more difficult.

On 23/07/15 20:09, David Feuer wrote:
> I'm very much in the "Damn the torpedoes; full speed ahead" camp most of
> the time, but not here. Transformers is a tiny step up from base. Why
> would you make it depend on template haskell rather than the other way
> around?
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: instance MonadIO Q

Edward Kmett-2
Alternately we could lift MonadIO into base.

This could be used eventually to lift more computations into MonadIO. Then nobody incurs an extra dependency and we have a first step towards more generic IO operations.

-Edward

On Thu, Jul 23, 2015 at 3:20 PM, Niklas Hambüchen <[hidden email]> wrote:
I'd also like to mention that there's a camp of people who'd like to
have a safe/pure version of TH that cannot do any IO - for changes like
the proposed one we should check whether they'd make that more difficult.

On 23/07/15 20:09, David Feuer wrote:
> I'm very much in the "Damn the torpedoes; full speed ahead" camp most of
> the time, but not here. Transformers is a tiny step up from base. Why
> would you make it depend on template haskell rather than the other way
> around?
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: instance MonadIO Q

David Feuer

Personally I'd think it sensible to push down Control.Monad.Trans.Class, Control.Monad.Trans.Reader, and Control.Monad.Trans.State.Strict into base. I don't know if any Writer or RWST variants are quite ready for that sort of treatment, and ListT obviously isn't.

On Jul 23, 2015 3:55 PM, "Edward Kmett" <[hidden email]> wrote:
Alternately we could lift MonadIO into base.

This could be used eventually to lift more computations into MonadIO. Then nobody incurs an extra dependency and we have a first step towards more generic IO operations.

-Edward

On Thu, Jul 23, 2015 at 3:20 PM, Niklas Hambüchen <[hidden email]> wrote:
I'd also like to mention that there's a camp of people who'd like to
have a safe/pure version of TH that cannot do any IO - for changes like
the proposed one we should check whether they'd make that more difficult.

On 23/07/15 20:09, David Feuer wrote:
> I'm very much in the "Damn the torpedoes; full speed ahead" camp most of
> the time, but not here. Transformers is a tiny step up from base. Why
> would you make it depend on template haskell rather than the other way
> around?
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: instance MonadIO Q

Edward Kmett-2
I'd hesitate to bring in MonadTrans or the rest of transformers into base, but MonadIO is fully non-controversial and fully Haskell 98. 

Lifting up and dropping that one module into base is a fairly simple change.

SPJ made a suggestion of adopting some more of the Data.Functor.* modules into base a year or so back. We took him up on the idea of Identity, but punted on the remainder. It may make sense to put together a separate proposal for the integration of Data.Functor.{Sum, Product, Compose}.

I would only support either proposal if they brought the modules in unmolested, without bikeshedding.

This would leave the "transformers" in the transformers package.

There are reasons not to like the existing MonadTrans class and reasons as well not to change it. There is also no need for it in base, nothing in base is set up in a fashion that it'd even be possible to make use of it to generalize any existing signatures.

-Edward

On Thu, Jul 23, 2015 at 4:08 PM, David Feuer <[hidden email]> wrote:

Personally I'd think it sensible to push down Control.Monad.Trans.Class, Control.Monad.Trans.Reader, and Control.Monad.Trans.State.Strict into base. I don't know if any Writer or RWST variants are quite ready for that sort of treatment, and ListT obviously isn't.

On Jul 23, 2015 3:55 PM, "Edward Kmett" <[hidden email]> wrote:
Alternately we could lift MonadIO into base.

This could be used eventually to lift more computations into MonadIO. Then nobody incurs an extra dependency and we have a first step towards more generic IO operations.

-Edward

On Thu, Jul 23, 2015 at 3:20 PM, Niklas Hambüchen <[hidden email]> wrote:
I'd also like to mention that there's a camp of people who'd like to
have a safe/pure version of TH that cannot do any IO - for changes like
the proposed one we should check whether they'd make that more difficult.

On 23/07/15 20:09, David Feuer wrote:
> I'm very much in the "Damn the torpedoes; full speed ahead" camp most of
> the time, but not here. Transformers is a tiny step up from base. Why
> would you make it depend on template haskell rather than the other way
> around?
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries



_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: instance MonadIO Q

Evan Laforge
On Thu, Jul 23, 2015 at 1:35 PM, Edward Kmett <[hidden email]> wrote:
> I'd hesitate to bring in MonadTrans or the rest of transformers into base,
> but MonadIO is fully non-controversial and fully Haskell 98.

Doesn't GHC internally have its own MonadIO?  I remember being really
confused by type errors from the GHC API until I figured out that the
MonadIO it used was not the one I was expecting.  It would be nice to
merge those.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: instance MonadIO Q

Ryan Scott
In reply to this post by Ryan Scott
It looks like GHC's internal MonadIO was replaced with the one from
transformers in 2013 [1], so this is already fixed.

Also, +1 on the MonadIO to base suggestion, now that's there's some
momentum behind that idea.

----------
[1] http://git.haskell.org/ghc.git/blobdiff/b13d546f9c454e6d2a15c20a3e10ec47328e33db..71feb1025eed0c3cc849c85e2b00e16bc1a21790:/compiler/utils/MonadUtils.hs
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: instance MonadIO Q

Matthias Hörmann
Is there a particular reason to still push MonadIO even though
MonadBase (from transformers-base) is a cleaner, more
general approach that also fits much more nicely with more powerful
abstractions like MonadBaseControl (from monad-control)?

I know it uses MultiParamTypeClasses but is there another, more
practical reason for not using MonadBase IO instead of MonadIO?

On Thu, Jul 23, 2015 at 11:29 PM, Ryan Scott <[hidden email]> wrote:

> It looks like GHC's internal MonadIO was replaced with the one from
> transformers in 2013 [1], so this is already fixed.
>
> Also, +1 on the MonadIO to base suggestion, now that's there's some
> momentum behind that idea.
>
> ----------
> [1] http://git.haskell.org/ghc.git/blobdiff/b13d546f9c454e6d2a15c20a3e10ec47328e33db..71feb1025eed0c3cc849c85e2b00e16bc1a21790:/compiler/utils/MonadUtils.hs
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: instance MonadIO Q

Edward Kmett-2
MonadIO remains Haskell 98. This means that it has a chance of actually getting into core libraries in a standardizable form and eventually making it into the report.

The problem is there is no full description of MultiParamTypeClasses + FunctionalDependencies that is compatible with all the implementations out there to bless and readily standardize. GHC and Hugs (and older GHCs) disagree on a number of corner cases of how this works. 

Worse, the corner cases where they disagree come up because of how GHC desugars things into type families, so describing current GHC behavior really would require dragging into the report pretty much all of OutsideIn(X), which is an order of magnitude more complicated than the entire report today.

So, yes, if we ever want to be able to see the bulk of the combinators in base lifted generalized and have that fact become enshrined in a standard then there is a very real reason to favor MonadIO.

-Edward

On Wed, Jul 29, 2015 at 9:30 AM, Matthias Hörmann <[hidden email]> wrote:
Is there a particular reason to still push MonadIO even though
MonadBase (from transformers-base) is a cleaner, more
general approach that also fits much more nicely with more powerful
abstractions like MonadBaseControl (from monad-control)?

I know it uses MultiParamTypeClasses but is there another, more
practical reason for not using MonadBase IO instead of MonadIO?

On Thu, Jul 23, 2015 at 11:29 PM, Ryan Scott <[hidden email]> wrote:
> It looks like GHC's internal MonadIO was replaced with the one from
> transformers in 2013 [1], so this is already fixed.
>
> Also, +1 on the MonadIO to base suggestion, now that's there's some
> momentum behind that idea.
>
> ----------
> [1] http://git.haskell.org/ghc.git/blobdiff/b13d546f9c454e6d2a15c20a3e10ec47328e33db..71feb1025eed0c3cc849c85e2b00e16bc1a21790:/compiler/utils/MonadUtils.hs
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: instance MonadIO Q

Ryan Scott
In reply to this post by Ryan Scott
Since almost two weeks have passed since I originally started this
thread, I'd be willing to submit patches which would

1. Move MonadIO from transformers to base
2. Introduce a MonadIO Q instance

I'm not sure what the etiquette for #1 is, however, since that would
require a change to a GHC dependency (transformers). Should I first
submit a patch that hides Control.Monad.IO.Class from GHC's
transformers fork if impl(ghc >= 7.11) (similar to this commit [1]),
and then submit an additional patch that adds Control.Monad.IO.Class
to base? Or would it suffice to do both in one go?

Ryan

-----
[1] http://git.haskell.org/packages/transformers.git/commitdiff/refs/heads/wip/T9664
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries