
Hi, I was rewriting my threads package to use TVars instead of MVars when I noticed that the following gave a type error: new ∷ IO ThreadGroup new = atomically $ ThreadGroup <$> newTVar 0 <*> newTMVar () because of a missing Applicative instance for STM. So I propose adding one: http://hackage.haskell.org/trac/ghc/ticket/4076 Discussion period: a few days, since I think this is hardly controversial. Regards, Bas

On Sun, May 16, 2010 at 01:54:28PM +0200, Bas van Dijk wrote:
I was rewriting my threads package to use TVars instead of MVars when I noticed that the following gave a type error: new ∷ IO ThreadGroup new = atomically $ ThreadGroup <$> newTVar 0 <*> newTMVar () because of a missing Applicative instance for STM.
So I propose adding one:
http://hackage.haskell.org/trac/ghc/ticket/4076
Note I had to create a base/Control/Applicative.hs-boot file and import Applicative using {-# SOURCE #-} because I got a "Module imports form a cycle for modules" error.
It might be simpler to have Control/Applicative.hs import GHC.Conc and define the instance. Might as well define an Alternative instance too. It would also make sense to move the MonadPlus instance from Control.Monad.STM (where it is an orphan) to GHC.Conc.
Discussion period: a few days, since I think this is hardly controversial.
I think proposals should get at least a couple of weeks, even if they're straightforward.

On Sun, May 16, 2010 at 4:19 PM, Ross Paterson
It might be simpler to have Control/Applicative.hs import GHC.Conc and define the instance.
The {-# SOURCE #-} import of Control.Applicative and the accompanying boot file are indeed unfortunate. However, I like having the Functor, Applicative and Monad instances in one place. But I can easily be convinced if more people like it your way.
Might as well define an Alternative instance too.
Good point, I will try adding them to the existing patches.
It would also make sense to move the MonadPlus instance from Control.Monad.STM (where it is an orphan) to GHC.Conc.
I created a separate ticket for this (including patches): http://hackage.haskell.org/trac/ghc/ticket/4077 But lets keep the discussion about that on this thread.
Discussion period: a few days, since I think this is hardly controversial.
I think proposals should get at least a couple of weeks, even if they're straightforward.
Ok, let's set the period on 2 weeks. If this proposal does proves to be controversial I will extend the period lateron. Thanks for your comments and suggestions! Bas

On Sun, May 16, 2010 at 06:36:56PM +0200, Bas van Dijk wrote:
On Sun, May 16, 2010 at 4:19 PM, Ross Paterson
wrote: It might be simpler to have Control/Applicative.hs import GHC.Conc and define the instance.
The {-# SOURCE #-} import of Control.Applicative and the accompanying boot file are indeed unfortunate. However, I like having the Functor, Applicative and Monad instances in one place. But I can easily be convinced if more people like it your way.
I would prefer to avoid the import loop. Thanks Ian

On Sun, May 16, 2010 at 7:10 PM, Ian Lynagh
On Sun, May 16, 2010 at 06:36:56PM +0200, Bas van Dijk wrote:
On Sun, May 16, 2010 at 4:19 PM, Ross Paterson
wrote: It might be simpler to have Control/Applicative.hs import GHC.Conc and define the instance.
The {-# SOURCE #-} import of Control.Applicative and the accompanying boot file are indeed unfortunate. However, I like having the Functor, Applicative and Monad instances in one place. But I can easily be convinced if more people like it your way.
I would prefer to avoid the import loop.
I just created a new patch that adds the Applicative and Alternative instances for GHC.Conc.STM to Control.Applicative (guarded in a #ifdef __GLASGOW_HASKELL__ block). Bas

On Sun, May 16, 2010 at 7:24 PM, Bas van Dijk
I just created a new patch that adds the Applicative and Alternative instances for GHC.Conc.STM to Control.Applicative (guarded in a #ifdef __GLASGOW_HASKELL__ block).
+1 from me here. I have a few uses for an applicative and alternative instance of STM. -- J.

On Mon, May 17, 2010 at 10:27 AM, Jesper Louis Andersen
On Sun, May 16, 2010 at 7:24 PM, Bas van Dijk
wrote: I just created a new patch that adds the Applicative and Alternative instances for GHC.Conc.STM to Control.Applicative (guarded in a #ifdef __GLASGOW_HASKELL__ block).
+1 from me here. I have a few uses for an applicative and alternative instance of STM.
Also +1 from me. I needed to work around STM not having an Applicative instance in an as of yet unreleased package.

+1 from me for either solution.
On Sun, May 16, 2010 at 1:24 PM, Bas van Dijk
On Sun, May 16, 2010 at 7:10 PM, Ian Lynagh
wrote: On Sun, May 16, 2010 at 06:36:56PM +0200, Bas van Dijk wrote:
On Sun, May 16, 2010 at 4:19 PM, Ross Paterson
wrote: It might be simpler to have Control/Applicative.hs import GHC.Conc and define the instance.
The {-# SOURCE #-} import of Control.Applicative and the accompanying boot file are indeed unfortunate. However, I like having the Functor, Applicative and Monad instances in one place. But I can easily be convinced if more people like it your way.
I would prefer to avoid the import loop.
I just created a new patch that adds the Applicative and Alternative instances for GHC.Conc.STM to Control.Applicative (guarded in a #ifdef __GLASGOW_HASKELL__ block).
Bas _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Hello, This is just a reminder and summary of my proposal to add Applicative and Alternative instances for STM. We're in the second and last week of this proposal. Ticket: http://hackage.haskell.org/trac/ghc/ticket/4076 Here's a description of the proposed patches: * stm_applicative-instance-sequential-stm.dpatch: This patch adds an Applicative instance for Control.Sequential.STM. Note that it doesn't add an Alternative instance because sequential STM does not support retrying transactions. Now for the regular STM there are actually two modules where we can define the Applicative and Alternative instances: GHC.Conc (which defines the type) and Control.Applicative (which defines the classes). The former has the advantage that the Functor, Applicative and Monad instances are grouped together. The disadvantage is that it requires to import Control.Applicative via {-# SOURCE #-} because we get an import cycle otherwise and so also requires the Control/Applicative.hs-boot file. The following patch makes this change: * base_applicative-instance-stm.dpatch More people like to add the instances to Control.Applicative however. The following patch makes that change: * base_add_applicative_and_alternative_instances_for_STM_to_Control.Applicative.dpatch Note there's a related proposal with patches for moving the MonadPlus instance for STM from Control.Monad.STM to GHC.Conc to avoid an orphaned instance. See: http://hackage.haskell.org/trac/ghc/ticket/4077 One last thing, I actually used to different Applicative instances for STM: The one in Control.Applicative: instance Applicative STM where pure = return (<*>) = ap Or the one in GHC.Conc: instance Applicative STM where {-# INLINE pure #-} {-# INLINE (<*>) #-} pure = returnSTM (<*>) = appSTM returnSTM :: a -> STM a returnSTM x = STM (\s -> (# s, x #)) appSTM :: STM (a -> b) -> STM a -> STM b appSTM (STM mf) (STM mx) = STM ( \s -> case mf s of (# s', f #) -> case mx s' of (# s'', x #) -> (# s'', f x #) ) Currently I don't have time to investigate if one is more efficient than the other. Does anybody have a hunch? Regards, Bas

The deadline for the proposal to add Applicative and Alternative
instances for STM has passed. Nobody rejected and some people
accepted.
It would be great if somebody can apply the patches:
* http://hackage.haskell.org/trac/ghc/attachment/ticket/4076/stm_applicative-i...
* http://hackage.haskell.org/trac/ghc/attachment/ticket/4076/base_add_applicat...
Thanks,
Bas
On Tue, May 25, 2010 at 1:20 AM, Bas van Dijk
Hello,
This is just a reminder and summary of my proposal to add Applicative and Alternative instances for STM. We're in the second and last week of this proposal.
Ticket: http://hackage.haskell.org/trac/ghc/ticket/4076
Here's a description of the proposed patches:
* stm_applicative-instance-sequential-stm.dpatch: This patch adds an Applicative instance for Control.Sequential.STM. Note that it doesn't add an Alternative instance because sequential STM does not support retrying transactions.
Now for the regular STM there are actually two modules where we can define the Applicative and Alternative instances: GHC.Conc (which defines the type) and Control.Applicative (which defines the classes).
The former has the advantage that the Functor, Applicative and Monad instances are grouped together. The disadvantage is that it requires to import Control.Applicative via {-# SOURCE #-} because we get an import cycle otherwise and so also requires the Control/Applicative.hs-boot file. The following patch makes this change: * base_applicative-instance-stm.dpatch
More people like to add the instances to Control.Applicative however. The following patch makes that change: * base_add_applicative_and_alternative_instances_for_STM_to_Control.Applicative.dpatch
Note there's a related proposal with patches for moving the MonadPlus instance for STM from Control.Monad.STM to GHC.Conc to avoid an orphaned instance. See: http://hackage.haskell.org/trac/ghc/ticket/4077
One last thing, I actually used to different Applicative instances for STM:
The one in Control.Applicative: instance Applicative STM where pure = return (<*>) = ap
Or the one in GHC.Conc: instance Applicative STM where {-# INLINE pure #-} {-# INLINE (<*>) #-} pure = returnSTM (<*>) = appSTM
returnSTM :: a -> STM a returnSTM x = STM (\s -> (# s, x #))
appSTM :: STM (a -> b) -> STM a -> STM b appSTM (STM mf) (STM mx) = STM ( \s -> case mf s of (# s', f #) -> case mx s' of (# s'', x #) -> (# s'', f x #) )
Currently I don't have time to investigate if one is more efficient than the other. Does anybody have a hunch?
Regards,
Bas
participants (6)
-
Bas van Dijk
-
Edward Kmett
-
Ian Lynagh
-
Jesper Louis Andersen
-
Roel van Dijk
-
Ross Paterson