- Libraries - Haskell.org

Re: Enum and bounded instances for (,) and Either
by Carter Schonwald 27 May '21

27 May '21

This raises a good point: enum as it currently exists is pretty bad and not well behaved ! On Sat, May 15, 2021 at 10:54 AM Zemyla <zemyla(a)gmail.com> wrote: > We can't write instances of Enum for (,) and Either until we have total > versions of pred and succ. > > On Wed, May 12, 2021, 20:11 Carter Schonwald <carter.schonwald(a)gmail.com> > wrote: > >> *while we could >> >> Perhaps we should provide these flavors via new types and thus folks >> could still benefit from these instances by way of deriving via ? >> >> On Wed, May 12, 2021 at 6:38 PM Carter Schonwald < >> carter.schonwald(a)gmail.com> wrote: >> >>> isnt there also the issue that while we good provide newtypes for >>> various choices of product of enum instance => enum of products, there >>> literally quite easily 3 valid instances we could concoct (and many more >>> besides) >>> >>> "row by row" >>> "column by column" >>> "diagonalization" >>> etc? >>> that is: each of these is just as valid? >>> >>> On Wed, May 12, 2021 at 5:46 PM Edward Kmett <ekmett(a)gmail.com> wrote: >>> >>>> Nothing indicates that minBound is >= 0. >>>> >>>> So if you want to deal with a modulus properly you need to deal with a >>>> modulus of something like maxBound - minBound + 1 (after appropriately >>>> upcasting intermediate results to a large enough type to contain that >>>> range). >>>> >>>> You also run into range issues pretty early on, and then scenarios like >>>> the instances for Float that are even wonkier. >>>> >>>> If toEnum/fromEnum went to a larger type (Integer or Natural) and we >>>> didn't have the wonkier Float instances and the like this would be a much >>>> easier sell. As it is I find myself rather uncomfortable with the shakiness >>>> of the foundations this thing rests upon. >>>> >>>> Sent from my iPhone >>>> >>>> On May 12, 2021, at 10:53 AM, Sandy Maguire <sandy(a)sandymaguire.me> >>>> wrote: >>>> >>>> >>>> Hi all, >>>> >>>> Found myself puzzled the other day when I wanted an (Enum a, Enum b) >>>> => Enum (a, b) instance, and was distraught that it didn't exist. >>>> >>>> The following is a reasonable implementation: >>>> >>>> >>>> instance (Bounded b, Enum a, Enum b) => Enum (a, b) where >>>> fromEnum (a, b) = (fromEnum (maxBound @b) + 1) * fromEnum a + >>>> fromEnum b >>>> toEnum n = >>>> let bound = fromEnum (maxBound @b) + 1 >>>> b = n `rem` bound >>>> a = n `div` bound >>>> in (toEnum a, toEnum b) >>>> >>>> And, while we're at it, might as well add canonical instances for >>>> Either: >>>> >>>> >>>> instance (Bounded a, Bounded b) => Bounded (Either a b) where >>>> minBound = Left minBound >>>> maxBound = Right maxBound >>>> >>>> instance (Bounded a, Enum a, Enum b) => Enum (Either a b) where >>>> toEnum i = >>>> let bound = fromEnum (maxBound @a) + 1 >>>> in case i < bound of >>>> True -> Left $ toEnum i >>>> False -> Right $ toEnum $ i - bound >>>> fromEnum (Left a) = fromEnum a >>>> fromEnum (Right b) = fromEnum b + fromEnum (maxBound @a) + 1 >>>> >>>> Are there any reasons these instances are missing from base? >>>> >>>> Cheers, >>>> Sandy >>>> >>>>> >>>>> _______________________________________________ >>>> Libraries mailing list >>>> Libraries(a)haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>> >>>> _______________________________________________ >>>> Libraries mailing list >>>> Libraries(a)haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>> >>> _______________________________________________ >> Libraries mailing list >> Libraries(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >

1 0

Re: Enum and bounded instances for (,) and Either
by Sandy Maguire 12 May '21

12 May '21

Hi all, Found myself puzzled the other day when I wanted an (Enum a, Enum b) => Enum (a, b) instance, and was distraught that it didn't exist. The following is a reasonable implementation: instance (Bounded b, Enum a, Enum b) => Enum (a, b) where fromEnum (a, b) = (fromEnum (maxBound @b) + 1) * fromEnum a + fromEnum b toEnum n = let bound = fromEnum (maxBound @b) + 1 b = n `rem` bound a = n `div` bound in (toEnum a, toEnum b) And, while we're at it, might as well add canonical instances for Either: instance (Bounded a, Bounded b) => Bounded (Either a b) where minBound = Left minBound maxBound = Right maxBound instance (Bounded a, Enum a, Enum b) => Enum (Either a b) where toEnum i = let bound = fromEnum (maxBound @a) + 1 in case i < bound of True -> Left $ toEnum i False -> Right $ toEnum $ i - bound fromEnum (Left a) = fromEnum a fromEnum (Right b) = fromEnum b + fromEnum (maxBound @a) + 1 Are there any reasons these instances are missing from base? Cheers, Sandy > >

7 8

Generalize indexing function
by Dannyu NDos 11 Apr '21

11 Apr '21

I noticed that the list indexing function, (!!), is generalizable. I'm showing some instances: {-# LANGUAGE MultiParamTypeClasses #-} import Data.Complex import Data.Functor.Compose import Data.Functor.Product import Data.Functor.Sum import Data.List.NonEmpty import Data.Maybe infix 9 !? infixl 9 ! class Indexable i a where (!?) :: i b -> a -> Maybe b (!) :: Indexable i a => i b -> a -> b x ! n = fromJust (x !? n) instance Indexable [] Int where [] !? _ = Nothing (x:_) !? 0 = Just x (_:xs) !? n | n < 0 = Nothing | otherwise = xs !? (n-1) instance Indexable ((->) a) (Identity a) where f !? Identity n = Just (f n) instance Indexable ((,) a) () where (_,x) !? _ = Just x instance Indexable Complex Bool where (x :+ _) !? False = Just x (_ :+ y) !? True = Just y instance (Indexable f a, Indexable g b) => Indexable (Compose f g) (a,b) where Compose z !? (m,n) = do y <- z !? m y !? n instance (Indexable f a, Indexable g b) => Indexable (Product f g) (Either a b) where Pair x _ !? Left m = x !? m Pair _ y !? Right n = y !? n instance (Indexable f a, Indexable g a) => Indexable (Sum f g) (Identity a) where InL x !? Identity n = x !? n InR y !? Identity n = y !? n instance Indexable NonEmpty Int where (x :| xs) !? n = (x : xs) !? n

7 11

template-haskell 2.17.0.0 not on Hackage
by Travis Cardwell 29 Mar '21

29 Mar '21

Hi, I noticed that template-haskell 2.17.0.0 has not been released to Hackage. One consequence of this is that the Hackage Dependency Monitor does not notify package maintainers of the major release. Releasing the new version on Hackage may prompt more package maintainers to update typed Template Haskell API code so that it works with GHC 9. Regards, Travis

6 6

Proposal: export more Data.Sequence internals
by David Feuer 16 Mar '21

16 Mar '21

I'd like containers to export more Data.Sequence internals, and to do so in a way that allows external users to rely on them. I propose the following: 1. Add a module, Data.FingerTree.IntPlus, abstractly exporting the finger trees used to represent sequences. These can also be used for other finger trees with measurements in the (Int, +) monoid. This would include various basic operations for cons, snoc, and splitting, with most names the same as for sequences. 2. Add a module, Data.FingerTree.IntPlus.Unsafe, exporting efficient mapping/traversing functions that rely on specific preconditions to maintain the internal fingertree annotation invariant. 3. Add a module, Data.Sequence.StableInternal, exporting the internal structure of sequences and also some internal functions that may be useful elsewhere (I'm particularly interested in the `splitMap` function and future variants thereof). Unlike the `.Internal` module, this module would be subject to the package version policy, and would therefore be more suitable for use by other packages. I am very open to suggestions for modifications to the module names. One option might be to put all the FingerTree.IntPlus stuff in the Data.Sequence.StableInternal hierarchy, if folks think it should be buried a bit. David

5 5

Proposal: add replay function to Control.Monad.Cont.Class
by Alexandre Esteves 13 Mar '21

13 Mar '21

I'd like to propose adding the following function (method?) to Control.Monad.Cont.Class, possibly with another name: replay :: MonadCont m => m (m a) replay = callCC $ pure . fix Using this in a do-notation block allows one to bind a name to the sub-block that starts immediately after. I reached for continuations to try to get this behavior for use with recursive flows without disrupting the reading of the main forward flow and found how to do it in https://jsdw.me/posts/haskell-cont-monad/ under the name "goto". While "goto" is as familiar as a name can be, I feel "replay" more accurately conveys, that you can only 'go back', by stating what actually is happening - that a sub-block we're currently evaluating is replayed from its beginning. As a motivating example, here's the same recursive IO flow written in 3 ways - one with replay, one with fix, and one with where clauses. {-# LANGUAGE LambdaCase #-} import Control.Monad.Cont.Class (MonadCont(callCC)) import Control.Monad.IO.Class (MonadIO, liftIO) import Control.Monad.Trans.Cont (evalContT) import Data.Function (fix) import Text.Read (readMaybe) replay :: MonadCont m => m (m a) replay = callCC $ pure . fix prompt :: MonadIO m => String -> m String prompt t = liftIO $ do putStrLn t putStr "> " getLine flowContT :: IO () flowContT = evalContT $ do liftIO $ putStrLn "Welcome to the totally not contrived game" numberPromptStep <- replay readMaybe <$> prompt "Pick a number" >>= \case Nothing -> liftIO (putStrLn "Not a number") *> numberPromptStep Just n -> liftIO $ putStrLn $ "You picked " <> show (n :: Int) exitPromptStep <- replay prompt "Stop? y/n" >>= \case "y" -> pure () "n" -> numberPromptStep _ -> liftIO (putStrLn "Invalid choice") *> exitPromptStep flowFix :: IO () flowFix = do putStrLn "Welcome to the totally not contrived game" fix $ \numberPromptStep -> do readMaybe <$> prompt "Pick a number" >>= \case Nothing -> liftIO (putStrLn "Not a number") *> numberPromptStep Just n -> liftIO $ putStrLn $ "You picked " <> show (n :: Int) fix $ \exitPromptStep -> do prompt "Stop? y/n" >>= \case "y" -> pure () "n" -> numberPromptStep _ -> liftIO (putStrLn "Invalid choice") *> exitPromptStep flowWhere :: IO () flowWhere = do putStrLn "Welcome to the totally not contrived game" numberPromptStep where numberPromptStep = do readMaybe <$> prompt "Pick a number" >>= \case Nothing -> liftIO (putStrLn "Not a number") *> numberPromptStep Just n -> do liftIO $ putStrLn $ "You picked " <> show (n :: Int) exitPromptStep exitPromptStep = do prompt "Stop? y/n" >>= \case "y" -> pure () "n" -> numberPromptStep _ -> liftIO (putStrLn "Invalid choice") *> exitPromptStep

6 7

Proposal: Add 'Foldable1' to base
by Reed Mullanix 22 Feb '21

22 Feb '21

With the recent discussion around the addition of 'intersection' to containers, I think it might be a good time to re-open the discussion surrounding adding 'Foldable1' to base. For context, 'Foldable1' would be a subclass of 'Foldable' that abstracts folds over non-empty containers. Alternatively, it can be seen as a method of combining together the elements of a container using a semigroup. The contents of this class have been discussed previously (See [1,2]), and the version presented in this proposal is taken from [1]. class Foldable t => Foldable1 t where {-# MINIMAL foldMap1 | foldr1map #-} fold1 :: Semigroup m => t m -> m -- the defining member, like foldMap but only asking for Semigroup foldMap1 :: Semigroup m => (a -> m) -> t a -> m -- strict foldMap1, cf foldMap' foldMap1' :: Semigroup m => (a -> m) -> t a -> m -- analogue of toList toNonEmpty :: t a -> NonEmpty a -- left&right, strict&non-strict folds foldr1 :: (a -> a -> a) -> t a -> a foldr1' :: (a -> a -> a) -> t a -> a foldl1 :: (a -> a -> a) -> t a -> a foldl1' :: (a -> a -> a) -> t a -> a -- these can have efficient implementation for NonEmptySet maximum1 :: Ord a => t a -> a minimum1 :: Ord a => t a -> a -- head1 have efficient implementation for NonEmpty and Tree -- last1 for symmetry head1 :: t a -> a last1 :: t a -> a -- fold variants with premap. -- Without this map, we cannot implement foldl using foldr etc. foldrMap1 :: (a -> b) -> (b -> b -> b) -> t a -> b foldlMap1' :: (a -> b) -> (b -> b -> b) -> t a -> b foldlMap1 :: (a -> b) -> (b -> b -> b) -> t a -> b foldrMap1' :: (a -> b) -> (b -> b -> b) -> t a -> b This has a couple of benefits. On the practical side, we can provide total alternatives to existing partial functions (IE: 'foldr1' and friends). It also enables us to fold over containers using a semigroup instance, which comes up suprisingly often. Naming: -------------------------------------------------------------------------------- Historically, the biggest source of controversy with this proposal has been over the name. The class currently exists in semigroupoids [3] under the name 'Foldable1', though there was some discussion around renaming it to 'SemiFoldable' [4]. However, if we keep the name unchanged, it makes the migration path nice and straightforward, and the possible name conflict with Data.Functor.Classes seems unlikely. Migration: -------------------------------------------------------------------------------- If we decide to go with 'Foldable1' as the name, we should be able to perform this change with 0 breakage. References: [1] https://mail.haskell.org/pipermail/libraries/2019-November/030059.html [2] https://gitlab.haskell.org/ghc/ghc/-/issues/13573 [3] https://hackage.haskell.org/package/semigroupoids-5.3.4/docs/Data-Semigroup… [4] https://github.com/ekmett/semigroupoids/issues/26

7 7

Text and changing number primops in GHC 9.2
by John Ericson 18 Feb '21

18 Feb '21

Hi all, First, background. I have a PR https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4492 <https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4492> that is one of the moving pieces for https://gitlab.haskell.org/ghc/ghc/-/issues/19026 <https://gitlab.haskell.org/ghc/ghc/-/issues/19026>, which is slated for 9.2 according to Ben's email https://mail.haskell.org/pipermail/ghc-devs/2021-February/019478.html <https://mail.haskell.org/pipermail/ghc-devs/2021-February/019478.html>. (I just added the milestone to the issue to reflect this.) Despite this being a breaking change (to unstable interfaces) containers, bytestring, and binary could all updated in a way that didn't used CPP. (See the linked PRs in the GHC !4492's description). Text is a different case, because the unboxed computation there is more pervasive. The current PR is https://github.com/haskell/text/pull/305 <https://github.com/haskell/text/pull/305>, and uses CPP for 9.2. We have a few different options: * Keep as is. There will surely be no perf regressions this way on any of the supported compilers. This does however mean adding CPP for 9.2 before the associated GHC change lands in master. I think that's fine---inevitable even based on the current policy for how GHC submodules are bumped---but it's given many library maintainers the heebie jeebies. * Try the same tricks in the other PRs of using hyper-local unboxing that is easy to unbox away. This will be a bit ugly however than the other cases, and I am not sure whether it won't be a regression for the oldest supported GHCs. * Do the above, but bump the base version to the point where there are no perf regressions with the oldest supported GHCs (because those compilers are no longer supported). If we bump the version more aggressively, perhaps we can get rid of much of the unboxing altogether / otherwise get rid of the ugliness. We'll need to reach some sort of decision here to move forward. I'll also add that while Oleg Grenrus has helped merge a preparatory PR, Oleg expressed a /dis/interest in being de facto text maintainer, so I am emailing the list in part so this does not fall upon Oleg alone any longer. John

3 4

Proposal: Expanding the CLC
by Emily Pillmore 17 Feb '21

17 Feb '21

Hi All, Over the past year, two things have become increasingly clear to me as I've carried out my CLC duties: 1. The CLC is under-resourced. This is evidenced by the fact that several maintainers who are not CLC members have been forced to step up to help take on some of the maintenance burden for many of the CLC libraries. Namely, `vector`, `bytestring`, `random`, `unix`, and more. The current CLC head count is not enough to dedicate at least one maintainer per package, which is leading to us all being spread thin, and the less-loved packages are falling into disrepair as a result. Couple this with the fact that roughly half the CLC do not have these packages actively within their maintenance cycles, and we arrive at the current problem. 2. The current set of "core" libraries does not cover what is generally considered "core" in the community. From now on, I'll refer to "core" packages as "boot" packages, and identify core packages to be those that are have proven to be incredibly popular tools for building things in Haskell. For example `zlib`, `parsec`, `regex-base`, `regex-posix`, `network`, etc. In particular, if any of these core packages saw their current authors disappear, or incapacitated in any sense, it would seriously harm the Haskell ecosystem. `cabal-install`, for example, requires several of those packages as upstream dependencies. Currently, we are dealing with this nightmare situation where work is stalled across many packages due to a particular set of maintainers being very difficult to reach, one of whom having disappeared completely for all maintenance intents and purposes. Ergo, we have a problem. Thankfully, many people have stepped up showing renewed interest in maintaining such packages with the latest crop of CLC folks, and this poses an interesting opportunity. My proposal is this: 1. We expand the CLC from 9 members to 22 members such that we have at least 1 CLC maintainer per boot package. There are a large number of fantastic candidates already available, who would be perfect for the role. In fact, many of the candidates whom we would ask are already maintaining these packages. In particular, Andrew Lelechenko, Simon Jakobi, Viktor Dukhovni, Dominic Steinitz, Alexey Khuedyakov are already serving within this role (and thank you for it!). Andreas Abel has also offered to help take on one of the core packages. 2. We consider a dedicated "Haskell Action Team" (name and idea courtesy of Carter Schonwald) to oversee packages in the Haskell github repo that can act as supplementary maintainers for many of the core packages contained therein. Currently, there are many in need of help. `zlib` comes to mind, which is currently blocking `bytestring-0.11` migration work due to having no available maintainer with the permissions to do a release. This, in turn, is stalling `cabal-install`. Short of taking over the package, we would have to ask for an emergency Hackage release if the neither maintainer shows up to do it in a reasonable time frame. This is just one step towards helping ease the burden of maintenance of so-called core and boot packages. I hope you agree that this is a good idea, and if we get enough thumbs up, then Chessai and I will draw up the necessary changes to the CLC remit and we'll get started! Cheers, Emily

11 15

Takeover / Comaintainership of Selda
by Thomas DuBuisson 17 Feb '21

17 Feb '21

I ask to take comaintainership of the four selda-* packages on hackage. While Anton was active months ago there are fixes that have languished for three weeks. I haven't heard from Anton in over a month, including on my offer to co-maintain a couple weeks back. It isn't my intent to full take over, just help maintain. My first points of action would be: - Merge the three most recent PRs of two critical bug fixes and a clean up. These would have to go on my own fork for the time being. - Release I know 3 weeks is short in the Haskell world for a package takeover. I only want to co-maintain and am ready to wait a while after sending this message in to see if Anton (CCed) awakens. -Tom

5 5