Should primMonad class live in base or mtl?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Should primMonad class live in base or mtl?

Carter Schonwald
This is something I’ve pondered on and off, And the classes PrimMonad and PrimMonadBase are super stable  


Argument in favor of base : 

there’s absolutely code in base, and packages like array, which would benefit from PrimMonad.   Plus it might allow more reuse / encourage more ST monad code in the wild? (I always feel like ST monad is underused. )

Argument against base: 
Then a lot of PrimMonad instances would need to live in transformers. And I’m not sure if maintainers over there would want that? 

Argument in favor of mtl: it’s where all the other transformer stack stuff gets defined. So all the upkeep for monad instances is already going on there regularly. 

Argument against mtl :  aside from concentrating the upkeep on transformer stack instances it seems like it wouldn’t enable new improvements to base.  


Another option is to have some sort of clone of the class in base , as long as it pays for itself in code reuse / simplification within base

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

Re: Should primMonad class live in base or mtl?

Andrew Martin
Relatedly, in an MR I started years ago but never finished, I did some work on the event manager to cut out a bunch of unneeded allocations [1]. This included replacing cons lists in several places with SmallArray. I had to copy in a bunch of code from primitive to do this. The strongest argument I see for moving some of primitive's machinery into base (and then reexporting it in primitive) is that there might be other places in base that could benefit from it. But I'm not certain of what those other places are.


On Mon, Jun 8, 2020 at 9:18 AM Carter Schonwald <[hidden email]> wrote:
This is something I’ve pondered on and off, And the classes PrimMonad and PrimMonadBase are super stable  


Argument in favor of base : 

there’s absolutely code in base, and packages like array, which would benefit from PrimMonad.   Plus it might allow more reuse / encourage more ST monad code in the wild? (I always feel like ST monad is underused. )

Argument against base: 
Then a lot of PrimMonad instances would need to live in transformers. And I’m not sure if maintainers over there would want that? 

Argument in favor of mtl: it’s where all the other transformer stack stuff gets defined. So all the upkeep for monad instances is already going on there regularly. 

Argument against mtl :  aside from concentrating the upkeep on transformer stack instances it seems like it wouldn’t enable new improvements to base.  


Another option is to have some sort of clone of the class in base , as long as it pays for itself in code reuse / simplification within base
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


--
-Andrew Thaddeus Martin

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

Re: Should primMonad class live in base or mtl?

George Wilson
Is it likely that other improvements to base would be enabled by this
move? If so, I think I'd be in favour of it, but I'm not sure it would
be worth the effort of the migration if there's only one or a couple.

On Mon, 8 Jun 2020 at 23:28, Andrew Martin <[hidden email]> wrote:

>
> Relatedly, in an MR I started years ago but never finished, I did some work on the event manager to cut out a bunch of unneeded allocations [1]. This included replacing cons lists in several places with SmallArray. I had to copy in a bunch of code from primitive to do this. The strongest argument I see for moving some of primitive's machinery into base (and then reexporting it in primitive) is that there might be other places in base that could benefit from it. But I'm not certain of what those other places are.
>
> [1] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/313
>
> On Mon, Jun 8, 2020 at 9:18 AM Carter Schonwald <[hidden email]> wrote:
>>
>> This is something I’ve pondered on and off, And the classes PrimMonad and PrimMonadBase are super stable
>>
>>
>> Argument in favor of base :
>>
>> there’s absolutely code in base, and packages like array, which would benefit from PrimMonad.   Plus it might allow more reuse / encourage more ST monad code in the wild? (I always feel like ST monad is underused. )
>>
>> Argument against base:
>> Then a lot of PrimMonad instances would need to live in transformers. And I’m not sure if maintainers over there would want that?
>>
>> Argument in favor of mtl: it’s where all the other transformer stack stuff gets defined. So all the upkeep for monad instances is already going on there regularly.
>>
>> Argument against mtl :  aside from concentrating the upkeep on transformer stack instances it seems like it wouldn’t enable new improvements to base.
>>
>>
>> Another option is to have some sort of clone of the class in base , as long as it pays for itself in code reuse / simplification within base
>> _______________________________________________
>> Libraries mailing list
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
>
> --
> -Andrew Thaddeus Martin
> _______________________________________________
> 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: Should primMonad class live in base or mtl?

Carter Schonwald
One opportunity would be to common up most of the interfaces for Mutable data structures that have both an io and st  version. Eg St ref and io ref.  The only reason we have both is because we don’t have PrimMonad in base!  

Likewise, stuff like the iomanager could perhaps be tweaked so we could do localized simulations in the st monad? 

On Sat, Jun 13, 2020 at 8:32 AM George Wilson <[hidden email]> wrote:
Is it likely that other improvements to base would be enabled by this
move? If so, I think I'd be in favour of it, but I'm not sure it would
be worth the effort of the migration if there's only one or a couple.

On Mon, 8 Jun 2020 at 23:28, Andrew Martin <[hidden email]> wrote:
>
> Relatedly, in an MR I started years ago but never finished, I did some work on the event manager to cut out a bunch of unneeded allocations [1]. This included replacing cons lists in several places with SmallArray. I had to copy in a bunch of code from primitive to do this. The strongest argument I see for moving some of primitive's machinery into base (and then reexporting it in primitive) is that there might be other places in base that could benefit from it. But I'm not certain of what those other places are.
>
> [1] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/313
>
> On Mon, Jun 8, 2020 at 9:18 AM Carter Schonwald <[hidden email]> wrote:
>>
>> This is something I’ve pondered on and off, And the classes PrimMonad and PrimMonadBase are super stable
>>
>>
>> Argument in favor of base :
>>
>> there’s absolutely code in base, and packages like array, which would benefit from PrimMonad.   Plus it might allow more reuse / encourage more ST monad code in the wild? (I always feel like ST monad is underused. )
>>
>> Argument against base:
>> Then a lot of PrimMonad instances would need to live in transformers. And I’m not sure if maintainers over there would want that?
>>
>> Argument in favor of mtl: it’s where all the other transformer stack stuff gets defined. So all the upkeep for monad instances is already going on there regularly.
>>
>> Argument against mtl :  aside from concentrating the upkeep on transformer stack instances it seems like it wouldn’t enable new improvements to base.
>>
>>
>> Another option is to have some sort of clone of the class in base , as long as it pays for itself in code reuse / simplification within base
>> _______________________________________________
>> Libraries mailing list
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
>
> --
> -Andrew Thaddeus Martin
> _______________________________________________
> 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: Should primMonad class live in base or mtl?

David Feuer
In reply to this post by Carter Schonwald
I'm opposed to moving it to base. This locks in base to GHC's fundamentally broken model of IO (in terms of functions passing state tokens) and also ties together the fundamentally different concepts of IO and ST. These issues tend to crop up in strictness analysis, and GHC has to continually tweak various internal hacks to keep users from noticing (most of the time). Let's not make future Haskells make these same decisions.

On Mon, Jun 8, 2020, 9:18 AM Carter Schonwald <[hidden email]> wrote:
This is something I’ve pondered on and off, And the classes PrimMonad and PrimMonadBase are super stable  


Argument in favor of base : 

there’s absolutely code in base, and packages like array, which would benefit from PrimMonad.   Plus it might allow more reuse / encourage more ST monad code in the wild? (I always feel like ST monad is underused. )

Argument against base: 
Then a lot of PrimMonad instances would need to live in transformers. And I’m not sure if maintainers over there would want that? 

Argument in favor of mtl: it’s where all the other transformer stack stuff gets defined. So all the upkeep for monad instances is already going on there regularly. 

Argument against mtl :  aside from concentrating the upkeep on transformer stack instances it seems like it wouldn’t enable new improvements to base.  


Another option is to have some sort of clone of the class in base , as long as it pays for itself in code reuse / simplification within base
_______________________________________________
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