- Libraries - Haskell.org

Laws for Show and Read?
by Dannyu NDos 16 Jun '19

16 Jun '19

Shouldn't it be laws that "show" must be injective and "read" must be surjective? Without such laws, one could define: data Foo = Foo instance Show Foo where show _ _ = id instance Read Foo where readPrec = pfail which should be prevented.

8 10

Strictness in Kinds
by Andrew Martin 14 Jun '19

14 Jun '19

TLDR: I wrote up an idea: https://gist.github.com/andrewthad/90a4b23051870d14afb4ba064699bc5b. Last night, the phrase "strictness in kinds" just stuck in my head. I could have sworn I'd heard it or read it before. But after some googling, I couldn't find anything on it. So, I started think about what it would look like for GHC to track strictness in the kind of an expression. It's kind of like proposals B2 and B3 from https://gitlab.haskell.org/ghc/ghc/wikis/unlifted-data-types, but I thought I'd share it here. -- -Andrew Thaddeus Martin

1 0

Proposal: Expose reverse topological ordering in Data.Graph
by James Parker 06 Jun '19

06 Jun '19

Hi, I’d like to expose reverse topological ordering in Data.Graph. I’ve created a pull request <https://github.com/haskell/containers/pull/638> that implements this. I named it `revTopSort` for now, but am fine with alternatives. Thanks, James Parker

2 2

add instance Monad (Arg a)
by Dannyu NDos 04 Jun '19

04 Jun '19

I think it's reasonable to make Arg as a writer monad with alternate ordering.

1 0

Memory Barriers with STM and MVar
by Andrew Martin 04 Jun '19

04 Jun '19

I've been poking around in old threads and in the GHC source, and I cannot find this documented anywhere. What are the guarantees that GHC provides around load/store reordering when it comes to using MVar or TVar+retry+atomically. For example: import Data.Primitive import Control.Concurrent.MVar ... foo :: IO () foo = do ... writeByteArray myArr 13 (42 :: Word) putMVar myMVar () If there is another thread that calls takeMVar followed by `readByteArray myArr 13`, is it guaranteed by GHC to see the 42 that's been written to the array. Same question applies for situations using STM facilities to accomplish blocking behavior that MVar gives us. Any documentation or pointers to places in GHC source where these barriers are guaranteed would be appreciated. -- -Andrew Thaddeus Martin

3 8

Add LiftA4 and LiftA5
by Dannyu NDos 28 May '19

28 May '19

It just feels so uncomforable that we have LiftM4 and LiftM5, but not Applicative versions of them.

4 4

Proposal: add isEmpty to Monoid
by Dr.Koster 25 May '19

25 May '19

It's often useful to have a generalized null/unit test, e.g. to check if a monadic stream `m a` reaches EOF. A workaround is to use `Eq a, Monoid a` constraint and use `== mempty` test. But this is no only inefficient for some type, but also impossible for some monoids, such as Builders. I propose add this test `isEmpty :: a -> Bool` to `Monoid`, to provide the ability to check if a value is the unit value. Cheers Han Dong~

3 3

request: a Nat ordering constraint that is not an equality constraint
by Nicolas Frisby 22 May '19

22 May '19

This email proposes an extension and possible change to GHC.TypeLits module in the core `base` library. Is there support for this kind of extension/change to GHC.TypeLits? If so, I'll open a GHC GitLab Issue. (If not, I would be very appreciate if someone were able to suggest a nice workaround.) # The Proposed Extension Please add an alternative to <= that is not defined via ~. For example: ``` module GHC.TypeLits.Passive where class IsTrue (a :: Bool) instance IsTrue 'True instance TypeError ... => IsTrue 'False type (<=) x y = IsTrue (x <=? y) ``` as opposed to the existing definition: ``` module GHC.TypeLits where type (<=) x y = (x <=? y) ~ 'True ``` Its name should be an operator and should be somewhat obvious -- I can't think of one other than <=, so I hedged here by putting in a new module instead. There should be a means of *explicitly* converting back and forth between evidence of the two constraints; they are equi-satisfiable but affect type inference in their scope differently. # The Optional Change I anticipate most users would prefer Passive.<= to today's <=, so the optional library change in this proposal is to redefine <= and relegate its old definition to a new name. Perhaps: ``` module GHC.TypeLits where type (<=) x y = IsTrue (x <=? y) type (<=!) x y = (x <=? y) ~ 'True ``` # The Motivation I'll explain with an example for some concreteness. I wrote an interface for size-indexed vectors for my employer. It involves some code like this: ``` import GHC.TypeLits newtype Fin (n :: Nat) = Unsafe_MkFin{forgetFin :: Integer} mkFin :: (KnownNat i,i <= n) => proxy i -> Fin n mkFin = Unsafe_MkFin . natVal ``` Constraints like `(i <= n)` show up throughout the library's interface. The problem is that <= is an equality constraint. Therefore many uses of `mkFin` et al *require* that I introduce local equality constraints. And those sadly spoil lots of desired type inference by making outer tyvars untouchable. That's the problem: I have to choose between GHC's specialized solving of <= constraints and unspoiled type inference in their scope. # Additional Context It is important that today's <= be an equality constraint, because it participates in some constraint improvements that introduce equality constraints. For example (x <= y,y <= x) implies x ~ y (c.f. the scary https://gitlab.haskell.org/ghc/ghc/issues/16586) Because <= constraints have the potential to "become" an equality constraint, tyvars outside of a <= constraint must be untouchable in its scope from the get go. However, neither my library nor any of its uses relies on such constraint improvements enabled by <= constraints. In this context, I would much rather that <= could never "become" an equality constraint, so that it need not be an equality constraint, so that it would never render a tyvar untouchable. # An Alternative As a partial workaround, I could write ``` data Dict i n = (i <= n) => MkDict mkFinD :: (KnownNat i) => Dict i n -> proxy i -> Fin n mkFinD MkDict = mkFin ``` and then take pains to only introduce the <= constraints in the argument of `mkFinD`. By limiting the scope of the ~ constraints like that, I could prevent them from spoiling the desired type inference. But it's very cumbersome to manage their scopes manually. # Work Estimation I just thought of the `IsTrue`-based approach while writing this email, so that detail is somewhat half-baked. It has the right *indicative* semantics, but I doubt today's GHC solver would know what to do with a Given `IsTrue (3 <=? 5)` constraint -- so I'm guessing that exact approach at least would require some significant changes in TcTypeNats. Thank you for your time. -Nick P.S. - Some of the issue tracker links at https://wiki.haskell.org/Library_submissions#The_Libraries respond with 404. P.P.S. - Is there a standard place to find something like `IsTrue`? More generally: a test for type equality that does not drive unification? Thanks again.

3 7

Proposal: DerivingVia, MTL
by Reed Mullanix 20 May '19

20 May '19

As it stands, working with newtypes around transformers can be kind of a pain. For example, consider newtype FreshT m a = { unFreshT :: StateT Int m a } deriving (Functor, Applicative, Monad, MonadReader r, ...) Right now, we can't just GND the instance: instance (MonadState s m) => MonadState s (FreshT m) However, the instance we end up writing is completely formulaic. Fortunately, we can solve this by using the recently added -XDerivingVia newtype Inner (t :: (* -> *) -> * -> *) m a = Inner { getInner :: t m a } deriving (Functor, Applicative, Monad) instance (MonadState s m) => MonadState s (Inner (StateT s') m) where get = Inner $ lift get put = Inner . lift . put This lets us derive the instance that we were looking for newtype FreshT m a = FreshT { unFreshT :: StateT Int m a } deriving newtype (Functor, Applicative, Monad, MonadReader r) deriving (MonadState s) via Inner (StateT Int) m This can be extended to other transformers/classes very easily. It also works well when dealing with newtyped transformer stacks. newtype FooT s e m a = FooT { unFooT :: StateT s (WriterT String (ExceptT e m)) a } deriving newtype (Functor, Applicative, Monad, MonadError e) deriving (MonadWriter w) via (StateT s (Inner (WriterT String) (ExceptT e m))) deriving (MonadState s') via Inner (StateT s) (WriterT String (ExceptT e m)) Cheers, Reed Mullanix

2 2

Proposal: add foldMapA to Data.Foldable or Control.Applicative
by Vanessa McHale 11 May '19

11 May '19

It's relatively easy to define foldMapA, viz. foldMapA :: (Monoid b, Traversable t, Applicative f) => (a -> f b) -> t a -> f b foldMapA = (fmap fold .) . traverse I've used found it useful once so far: http://hackage.haskell.org/package/dir-traverse-0.2.0.0/docs/src/System.Dir… Cheers, Vanessa McHale

9 19