April 2014 - Libraries

Proposal: merge either into transformers
by Roman Cheplyaka 03 Jan '17

03 Jan '17

I propose to add the sole module of the 'either' package[1], Control.Monad.Trans.Either, to the transformers package. It provides EitherT, a very basic and fundamental data type. The difference between EitherT and ErrorT is that the latter has an Error constraint, which is used to imlement 'fail'. Note that 'either' depends on the 'semigroupoids' and 'semigroup' packages to provide appropriate instances. The proposal is not to add those instances to 'transformers' to avoid additional dependencies. The instances can then be left in the 'either' package or moved to the 'semigroupoids' and 'semigroup' packages respectively. ('semigroupoids' already depends on 'transformers', while 'semigroups' does not). Compared to the 'either' package, Show, Read, Eq and Ord instances will be dropped to keep the code Haskell2010 (those instances require FlexibleInstances, FlexibleContexts, and UndecidableInstances). The patch is attached. [*] [*] against transformers-0.3.0.0, because the darcs version is not buildable (Control/Monad/Signatures.hs is not in the repository). Roman

22 72

Proposal: improve the Data.Tree API
by João Cristóvão 01 Jan '15

01 Jan '15

Hello, The Data.Tree API seems rather poor. Some research on hackage shows some additional functions being defined in very unrelated packages: http://hackage.haskell.org/package/debian-3.81/docs/Debian-Apt-Dependencies… http://hackage.haskell.org/package/hledger-lib-0.22.1/docs/Hledger-Utils.ht… I propose the addition of the following functions, that seem rather straigh forward to me: -- | get the sub-tree rooted at the first (left-most, depth-first) occurrence -- of the specified node value lookupTree :: Eq a => a -> Tree a -> Maybe (Tree a) -- | get the sub-tree rooted at the first (left-most, depth-first) value that -- matches the provided condition findTree :: (a -> Bool) -> Tree a -> Maybe (Tree a) -- | keep only the elements that match the provided condition filter :: (a -> Bool) -> Tree a -> Tree a The 'Tree' is appended in the name, to distinguish from the Foldable instances, that return the value, and not a sub-tree. Additionally, the following two functions might also be useful (even if the implementation is very simple in the second case): -- | get the sub-tree for the specified node value in the first tree in -- forest in which it occurs. lookupTreeInForest :: Eq a => a -> [Tree a] -> Maybe (Tree a) -- | Length of the tree length :: Tree a -> Int There are probably more useful functions to add, so suggestions are welcomed. Previous discussion: https://github.com/haskell/containers/issues/39#issuecomment-35799628 Discussion period: 2 weeks Cheers, João

12 35

Removing MonadFail from Monad
by David Luposchainsky 03 Oct '14

03 Oct '14

Hey everyone, I feel like there are a couple of elephants in the room that are sort of important but nobody really addresses them directly. One of them was what became the AMP, and `fail` is another one. I resurrected and refurbished this proposal from a 6 month old Gist because there seemed to be some interest/talk going on in the form of side remarks in other discussions here. The sun shines, let's make some hay! The proposal text can be found at the end of this text (for the mailman archives), or in pretty HTML here: https://github.com/quchen/articles/blob/master/monad_fail.md Although this will technically a language-level change, the impact will mainly be a library and fail-safety detail. For this reason I think this mailing list is more suitable than other more specialized lists. Greetings, David/quchen PS: I would have chosen Fail Removal Proposal so we have a new buzzword, but unfortunately it does not abbreviate well. Call it the "fail of Haskell issue"? ;-) Removing `fail` from `Monad` ============================ The problem ----------- Currently, the `<-` symbol is desugared as follows: ```haskell do pat <- computation >>> let f pat = more more >>> f _ = fail "..." >>> in computation >>= f ``` The problem with this is that `fail` cannot be sensibly implemented for many monads, for example `State`, `IO`, `Reader`. In those cases it defaults to `error`, i.e. the monad has a built-in crash. `MonadFail` class ----------------- To fix this, introduce a new typeclass: ```haskell class Monad m => MonadFail m where fail :: String -> m a ``` Desugaring is then changed to the following: ```haskell -- Explicitly irrefutable pattern: do not add MonadFail constraint do ~pat <- computation >>> let f pat = more more >>> in computation >>= f -- Only one data constructor: do not add MonadFail constraint do (Only x) <- computation >>> let f (Only x) = more more >>> in computation >>= f -- Otherwise: add MonadFail constraint do pat <- computation >>> let f pat = more more >>> f _ = fail "..." >>> in computation >>= f ``` Discussion ---------- - Although for many `MonadPlus` `fail _ = mzero`, a separate `MonadFail` class should be created. A parser might fail with an error message involving positional information, and for STM failure is undefined although it is `MonadPlus`. - The case of one data constructor should emit a warning if the data type is defined via `data`: adding another data constructor can make patterns in unrelated modules refutable. - Some monads use the pattern matching to force evaluation of the binding, for example lazy/strict `StateT`. I'm not sure what exactly the consequences of the above are here; I suspect a strictness annotation or `(>>=)` instead of `do` notation might be sufficient. - Getting the change to work should be boring but painless: all Monad instance declarations involving `fail` will break because the function is removed, and many monadic computations have to be annotated using `~` because they were written under the assumption that `fail` is never called. In both these cases compilation errors/warnings carry sufficient information to fix the source code easily. - Backwards compatibility with many old modules will be broken; I don't see a way around this. Other things to consider ------------------------ - Rename `fail`? It's quite a generic name that would be nice to have in APIs. `failM`? `mfail`? - Remove the `String` argument? (May hurt error reporting on pattern mismatch ..?) - How sensitive would existing code be to subtle changes in the strictness behaviour of `do` notation pattern matching? Applying the change ------------------- Like the AMP, 1. Implement ad-hoc warnings that code will receive a `MonadFail` constraint in a future version. "Either make the patterns irrefutable, or keep in mind that the next compiler version will require a `MonadFail` instance". Since `MonadFail` does not clash with an existing name, it could be introduced to `Control.Monad` right away. 2. Do the switch.

9 11

Proposal: Use time rather than old-time in directory
by Ian Lynagh 16 Sep '14

16 Sep '14

Hi all, This proposal is to change directory to use the time package rather than the old-time package. This will hopefully be a significant step towards actually making the transition in general. I'm not sure if POSIXTime or UTCTime is the better type to use. Does anyone know? I started off with UTCTime, then switched to POSIXTime as UTCTime didn't have a Show instance. I've since found that actually UTCTime has both Show and Read instances, but they are orphaned. So actually, if UTCTime is the better type then switching back to UTCTime would allow us to fix this comment in hpc: -- We would rather use ClockTime in Mix, but ClockTime has no Read instance and simplify the code slightly. Attached are patches for directory, hpc and ghc. Suggested discussion period: Until 5th Nov 2011. Thanks Ian

14 35

Proposal: Add Data.Semigroup to base, as a superclass of Monoid
by John Wiegley 11 Aug '14

11 Aug '14

1. I propose that we add the following package to base: http://hackage.haskell.org/packages/archive/semigroups/0.9.2/doc/html/Data-… This is somewhat in the spirit of the AMP proposal: further improving the correctness of our algebraic abstractions. 2. That we make Semigroup a superclass of Monoid, so that (minimally): class Semigroup a where (<>) :: a -> a -> a class Semigroup a => Monoid a where mempty :: a mconcat :: [a] -> a mconcat = foldr (<>) mempty mappend :: Semigroup a => a -> a -> a mappend = (<>) 3. (Optional, recommended) There are other useful functions that can be added to Semigroup, such as sconcat and times1p, but I will let Edward speak to whether those should be proposed at this time. 4. (Optional, recommended) That we fix the Monoid instance for Maybe to be: instance Semigroup a => Semigroup (Maybe a) where Just x <> Just y = Just (x <> y) _ <> _ = Nothing instance Semigroup a => Monoid (Maybe a) where mempty = Nothing For some clarification on what semigroups are and why we'd want to change Monoid, I excerpt here a selection from Brent Yorgey's "Monoids and Variations" paper: Semigroups A semigroup is like a monoid without the requirement of an identity element: it consists simply of a set with an associative binary operation.... Of course, any monoid is automatically a semigroup (by forgetting about its identity element). In the other direction, to turn a semigroup into a monoid, simply add a new distinguished element to serve as the identity, and extend the definition of the binary operation appropriately. This creates an identity element by definition, and it is not hard to see that it preserves associativity.... Adding a new distinguished element to a type is typically accomplished by wrapping it in Maybe. One might therefore expect to turn an instance of Semigroup into an instance of Monoid by wrapping it in Maybe. Sadly, Data.Monoid does not define semigroups, and has a Monoid instance for Maybe which requires a Monoid constraint on its argument type... This is somewhat odd: in essence, it ignores the identity element of [the type] and replaces it with a different one. -- John Wiegley FP Complete Haskell tools, training and consulting http://fpcomplete.com johnw on #haskell/irc.freenode.net

9 9

Gearing up (again) for the next release: 2014.2.0.0
by Mark Lentczner 30 May '14

30 May '14

SO, In anticipation of releasing a HP shortly (1 month?) after GHC 7.8... I'd like to get going on nailing down package versions. I've been working intently on the new Haskell Platform build process (see the new-build branch<https://github.com/haskell/haskell-platform/tree/new-build>), and have been building platforms against the release. Here is the description of versions I'm working with: [ incGHC "7.8" , incGHCLib "array" "0.5.0.0" , incGHCLib "base" "4.7.0.0" , incGHCLib "bytestring" "0.10.4.0" , incGHCLib "Cabal" "1.18.1.3" , incGHCLib "containers" "0.5.4.0" , incGHCLib "deepseq" "1.3.0.2" , incGHCLib "directory" "1.2.0.2" , incGHCLib "filepath" "1.3.0.2" , incGHCLib "haskell2010" "1.1.1.1" , incGHCLib "haskell98" "2.0.0.3" , incGHCLib "hpc" "0.6.0.1" , incGHCLib "old-locale" "1.0.0.6" , incGHCLib "old-time" "1.1.0.2" , incGHCLib "pretty" "1.1.1.1" , incGHCLib "process" "1.2.0.0" , incGHCLib "template-haskell" "2.9.0.0" , incGHCLib "time" "1.4.1" , incGHCLib "transformers" "0.3.0.0" , notWindows $ incGHCLib "unix" "2.7.0.1" , onlyWindows $ incGHCLib "Win32" "2.3.0.1" , incLib "async" "2.0.1.5" , incLib "attoparsec" "0.10.4.0" , incLib "case-insensitive" "1.1.0.3" , incLib "cgi" "3001.1.7.5" , incLib "fgl" "5.4.2.4" , incLib "GLUT" "2.5.0.2" , incLib "GLURaw" "1.4.0.0" , incLib "haskell-src" "1.0.1.5" , incLib "hashable" "1.2.1.0" , incLib "html" "1.0.1.2" , incLib "HTTP" "4000.2.10" , incLib "HUnit" "1.2.5.2" , incLib "mtl" "2.1.2" , incLib "network" "2.4.2.2" , incLib "OpenGL" "2.9.1.0" , incLib "OpenGLRaw" "1.4.0.0" , incLib "parallel" "3.2.0.4" , incLib "parsec" "3.1.5" , incLib "primitive" "0.5.2.1" , incLib "QuickCheck" "2.6" , incLib "random" "1.0.1.1" , incLib "regex-base" "0.93.2" , incLib "regex-compat" "0.95.1" , incLib "regex-posix" "0.95.2" , incLib "split" "0.2.2" , incLib "stm" "2.4.2" , incLib "syb" "0.4.1" , incLib "text" "1.1.0.0" , incLib "unordered-containers" "0.2.3.3" , incLib "vector" "0.10.9.1" , incLib "xhtml" "3000.2.1" , incLib "zlib" "0.5.4.1" , incTool "cabal-install" "1.18.0.3" , incTool "alex" "3.1.2" , incTool "happy" "1.19.2" , incTool "hscolour" "1.20.3" , incTool "haddock" "2.14.0" ] However, there are some issues to contend with: *Haddock* - is there any reason not to use the version built and distributed with GHC 7.8? *Shipped w/GHC* - GHC 7.8 ships with several more packages than we include in the platform. I want to review how these are handled: *possibly include in platform* - binary-0.7.1.0 - ghc-prim-0.3.1.0 - hoopl-3.10.0.0 *shouldn't include in platform* - bin-package-db-0.0.0.0 - integer-gmp-0.5.1.0 - rts-1.0 *shipped with GHC, but not registered in pkg-db, yet possible useful to include in platform:* - haskeline-0.7.1.2 - terminfo-0.4.0.0 - xhtml-3000.2.1 -- already in platform, but HP re-builds it... seems silly? *cgi* - no longer builds, and we've been unwilling to bring it forward because it pulls in MonadCatchIO-mtl *hscolour* - never approved as part of platform, but we use it to generate the haddock in both GHC and the Platform - shouldn't we just include it? *New packages:* Last time we had a bunch we wanted... but timing, especially vis-a-vis 7.8 and the new Builder classes, caused us to delay them. Shall we include: aeson dlist (needed by aeson, which version?) scientific (needed by aeson - or get aeson to subsume that code?) *anything else? now's the time to propose!* - Mark

29 135

Re: Add laws to Alternative
by Twan van Laarhoven 28 May '14

28 May '14

On 01/11/13 12:44, Nathan van Doorn wrote: > Firstly, I don't see how IO is relevant here, it has neither a MonadPlus > instance nor an Alternative instance. You are right. I thought it was an instance with mzero=fail "foo" and mplus=catch. But I was apparently mistaken. Objection withdrawn. > Secondly, the MonadPlus laws are documented in Control.Monad to be: > > mzero >>= f = mzero > v >> mzero = mzero I missed them, because they are written in the documentation of mzero rather than the documentation of the class where I expected them. > Thirdly, the monoid laws are already documented. (<|>) must be "An associative > binary operation", and empty "The identity of <|>". These are exactly the monoid > laws. Perhaps they should be made more explicit, but that is a different issue. Missed this as well. > Fourthly, [] fulfils neither the left-distribution law or the left-catch law, > and I doubt many people would be happy to lose []'s MonadPlus instance. List does satisfy left distribution: λ> (,) <$> ([1,2] <|> [3]) <*> [4,5] [(1,4),(1,5),(2,4),(2,5),(3,4),(3,5)] λ> (,) <$> [1,2] <*> [4,5] <|> (,) <$> [3] <*> [4,5] [(1,4),(1,5),(2,4),(2,5),(3,4),(3,5)] λ> quickCheck (\x y z -> ((,) <$> (x <|> y :: [Int]) <*> (z :: [Int])) == (((,) <$> x <*> z) <|> ((,) <$> y <*> z))) +++ OK, passed 100 tests. See also http://www.haskell.org/haskellwiki/MonadPlus. Then law which it doesn't is right distribution. Consider Maybe. it does satisfies left catch but not left distribution for MonadPlus. Since mplus (Just False >>= guard) (Just True >>= guard) = Just () while mplus (Just False) (Just True) >>= guard = Nothing But for Alternative, you can't have the failure of the second argument of (<*>) depend on the first. So Maybe *does* satisfy left distribution for Alternative. IMO that makes it a good candidate law. Twan > I believe I have addressed all your issues. If I've missed something, please > point it out to me. > > Nathan. > > > On 1 November 2013 12:09, Twan van Laarhoven <twanvl(a)gmail.com > <mailto:twanvl@gmail.com>> wrote: > > On 01/11/13 11:42, Nathan van Doorn wrote: > > Proposal: add the following laws to the documentation of > Control.Applicative.__Alternative: > > * empty <*> a = empty > * f <*> empty = empty > > > These laws correspond to the laws given in MonadPlus- if you take mzero = > > empty and ap = (<*>), the ones in MonadPlus imply these- and I don't think > > this proposal should be too controversial. > > As far as I can see, the documentation for MonadPlus does not specify these > laws anywhere [1,2]. > > Consider the IO monad. These laws claim that > > launchMissiles *> fail "empty" = fail "empty" > > This is clearly *not* true. > > -- > > If we add laws, I think we should first consider the much more reasonable > monoid laws > > identity > empty <|> a = a > a <|> empty = a > associativity: > (a <|> b) <|> c = a <|> (b <|> c) > > In the MonadPlus world, the controversial part is the choice between > > left distribution > (f <|> g) <*> a = (f <*> a) <|> (g <*> a) > > or > > left catch > pure a <|> b = pure a > > Your proposal would be > > left zero > > empty <*> a = empty > right zero > > f <*> empty = empty > > And as mentioned above, right zero is problematic. The fmap version should > be okay though > > map zero > f <$> empty = empty > > > Twan > > [1] > http://hackage.haskell.org/__package/base-4.6.0.1/docs/__Control-Monad.html… > <http://hackage.haskell.org/package/base-4.6.0.1/docs/Control-Monad.html#t:M…> > [2] http://www.haskell.org/__haskellwiki/MonadPlus > <http://www.haskell.org/haskellwiki/MonadPlus> > _________________________________________________ > Libraries mailing list > Libraries(a)haskell.org <mailto:Libraries@haskell.org> > http://www.haskell.org/__mailman/listinfo/libraries > <http://www.haskell.org/mailman/listinfo/libraries> > >

9 11

Strictifying monadic values, take 3
by David Luposchainsky 12 May '14

12 May '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 (HTML-rendered version of the text below see [1]) Strictifying Monadic values =========================== Half a year ago, Johan Tibell proposed adding a strict equivalent to fmap [2]. This discussion got lost in details, it was reopened, it ended in bikeshedding again. This is a third attempt to get this through, with individual options and no alternatives proposed, compiled from the two more popular responses in the other threads. Please do not propose alternative implementations here, we've been through this twice already. Vote ±1 on each point to show (dis)agreement. I think this functionality should be in the standard libraries in one way or another, regardless of how it's named in the end. 1. Add a strict version of <$>, named <$!>. ```haskell infixl 4 <$!> (<$!>) :: Monad m => (a -> b) -> m a -> m b f <$!> m = do x <- m return $! f x ``` This is closely related to fmap in terms of functionality, but requires a Monad constraint. This would allow defining ```haskell seqM m = id <$!> m ``` if such a function is needed. 2. Add a seqM function that evaluates the "contents" of a monadic action to WHNF. ```haskell seqM :: Monad m => m a -> m a seqM m = do x <- m return $! x ``` This is less close to fmap, but allows building other strict operations (locally and as needed) based on it easier, for example ```haskell f <$!> x = seqM ( f <$> x) mf <*!> mx = seqM (mf <*> mx) mf <*! mx = seqM (mf <* mx) mf *!> mx = seqM (mf *> mx) ``` If these operators then turn out to be used (and locally reinvented) very often by different people, reconsider adding them as well. A voting period of two weeks (until 10-05-2014) should be sufficient to allow everyone to join in. Greetings, David Links: [1]: https://github.com/quchen/articles/blob/master/seqm_proposal.md [2]: http://www.haskell.org/pipermail/libraries/2013-November/021728.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTXAWmAAoJELrQsaT5WQUs9GgH/3Vr2nDUDyX7pU24Vs0Dfq6e 43xcgY5ZBXCk/v/L6b14DA2br+jc32GkAnwkoWvJYQDNc6E6QwdPUnyaFpNPthA3 7NDcuGukJPzpkkA/YCVqq4Yu6jIwjcVm/xMQaRmASWMnlJxEypFuuMirWVUgg+ED Zl9x2VUoFUoRq6TpE1TGcOS0eoevqvu7LDdTJkGEC7wNxZOD4a2hjyiv90e2LmYL mP0pPKVj2NfSjIfDa/q+ONIHN+hrQqriku9OJSGU8UVxOfAvi86W42xsFV6fNdVE OKc/TTKM4V23G7qw3Dpz1EGnXqqLdYlv1ck2EF05tmSOjJ6Bx2lAUBypRyjX6IA= =+wNo -----END PGP SIGNATURE-----

5 5

Re: geniplate bump to template-haskell-2.9
by Andreas Abel 04 May '14

04 May '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear hackage admins, [CC: libraries(a)haskell.org] Another week has passed without action from either package maintainer or hackage admins. Am I following this protocol correctly? http://www.haskell.org/haskellwiki/Taking_over_a_package If I am lacking, let me know where, otherwise please do your part. Sincerly, Andreas On 23.04.2014 18:35, Andreas Abel wrote: > Dear Lennart, > > since we want to release Agda-2.3.4 soon to work with ghc-7.8, we > need a version of geniplate that works with new template haskell. > All that is required is an update of version bounds in the cabal > file (attached). > > Since you have not responded to our request, I am following > procedure > > http://www.haskell.org/haskellwiki/Taking_over_a_package > > to be able to upload an updated version of geniplate. > > Dear Hackage admins, > > here is proof of my public request for the update of geniplate: > > http://osdir.com/ml/libraries@haskell.org/2014-04/msg00191.html > > Please give me rights to upload a new version or do the dependency > bumps yourself (new cabal file attached). > > Cheers, AndreasAbel (hackage account id) > > - -- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel(a)gu.se http://www2.tcs.ifi.lmu.de/~abel/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNhaQkACgkQPMHaDxpUpLMSXgCfeU4ENXuReT6GeGhX4GVOWpXs JS0An016Bmq4MEA4EmwXJpmWgmRCUXoe =K9mb -----END PGP SIGNATURE-----

4 6

RFC: include a cabal-install executable in future GHC releases
by Carter Schonwald 03 May '14

03 May '14

Hey everyone, I'd like to propose that GHC releases 7.8.1 onwards include a cabal-install (aka cabal) executable, but not include the library deps of cabal-install that aren't already distributed with ghc.(unless ghc should have those deps baked in, which theres very very good reasons not to do.). currently if someone wants just a basic haskell install of the freshest ghc they have to install a ghc bindist, then do a boostrap build of cabal-install by hand (if they want to actually get anything done :) ). This is not a human friendly situation for folks who are new to haskell tooling, but want to try out haskell dev on a server style vm or the like! point being: It'd be great for haskell usability (and egads amounts of config time, even by seasoned users) the ghc bindists / installers included a cabal-install binary thoughts? -Carter

16 40