July 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

[containers] Proposal: Change to the Data.Map Monoid
by Nick Partridge 10 Oct '15

10 Oct '15

Hi, Currently the Monoid instance for Data.Map is implemented using union/unions, which are left biased. On key collision, it discards values from the right hand side of `mappend` - https://github.com/ghc/packages-containers/blob/bae098fb0a3994bc2b0ec331300… If you compare this with the Monoid for Maybe, it's like we're defaulting to First as the monoid instance for maps. A more useful instance, however very much a breaking change, would be to make the instance depend on a Monoid (or better yet, a Semigroup) for the values in the map: instance Monoid v => Monoid (Map k v) where mappend = unionWith mappend This lets us build up maps with values in a useful Monoid, and mappend them with gusto. Thoughts? - Nick Partridge Discussion period: 2 weeks.

15 22

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

Proposal: Add a strictly accumulating scanl' to Data.List
by David Feuer 28 Oct '14

28 Oct '14

Joachim Breitner wrote, in https://ghc.haskell.org/trac/ghc/ticket/9345#comment:6, a strictly accumulating version of scanl, to be named scanl'. I was initially concerned about its safety for fusion, but am now convinced of its correctness and believe it should be added to Data.List. scanl' :: (b -> a -> b) -> b -> [a] -> [b] scanl' f a bs = build $ \c n -> a `seq` a `c` foldr (\b g x -> (let b' = f x b in b' `seq` (b' `c` g b'))) (\b -> b `seq` n) bs a

3 3

Proposal: end lazy IO results with errors/exceptions
by David Feuer 10 Oct '14

10 Oct '14

Currently, withFile "foo" hGetContents >>= putStrLn prints out an empty line, the better to confuse newbies. I propose modifying the lazyRead function in GHC.IO.Handle.Text that currently reads lazyRead :: Handle -> IO String lazyRead handle = unsafeInterleaveIO $ withHandle "hGetContents" handle $ \ handle_ -> do case haType handle_ of ClosedHandle -> return (handle_, "") SemiClosedHandle -> lazyReadBuffered handle handle_ _ -> ioException (IOError (Just handle) IllegalOperation "hGetContents" "illegal handle type" Nothing Nothing) to something like lazyRead :: Handle -> IO String lazyRead handle = unsafeInterleaveIO $ withHandle "hGetContents" handle $ \ handle_ -> do case haType handle_ of ClosedHandle -> return (handle_, error "Forcing the result of a lazy read led to an attempt to read from a closed handle.") SemiClosedHandle -> lazyReadBuffered handle handle_ _ -> ioException (IOError (Just handle) IllegalOperation "hGetContents" "illegal handle type" Nothing Nothing) Ideally that error should instead be something to throw an imprecise exception, but I don't know how to use those yet. I can't personally see a way for this to break sane, working code, but the folks on #ghc thought it should be discussed and debated on list. David Feuer

10 12

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

Re: Formal proposal: replace Data.List.inits
by David Feuer 06 Sep '14

06 Sep '14

Minor errors in copying/memory: initsHO = map ($[]) . scanl q id where q f x = f . (x :) On Sun, Jul 20, 2014 at 2:03 AM, David Feuer <david.feuer(a)gmail.com> wrote: > As previously discussed, Data.List.inits has terrible performance: > something as simple as > > print $ length $ inits [100000] > > will take an absurdly long time. The simplest decent improvement seems to be > > initsHO = map ($[]) . scanl q [] > where > q f x = f . (q :) > > A slight transformation of this by Andrew Seniuk (rasfar on #haskell) > gives the slightly faster > > initsR = map reverse . scanl (flip (:)) [] > > As Henning Thielemann and Edward Kmett pointed out, these perform > poorly when calculating things like `map head $ drop 100000 $ inits > [100050]` because the costs of the reverses or compositions are > monolithic and unshared. Edward Kmett pointed out that this could > probably be fixed by using a queue (although he isn't sure it's worth > doing so). As it turns out, it can, and with only a trivial penalty in > other cases. The following uses a stripped-down partial implementation > of Okasaki's banker's queue (see the attached file for a version with > explanatory comments as well as the benchmark code): > > import Data.Bits (popCount) > import Data.Word (Word) > > data Queue a = Queue {-# UNPACK #-} !Word [a] [a] > > queue :: Word -> [a] -> [a] -> Queue a > queue lp1 f r > | popCount lp1 /= 1 = Queue lp1 f r > | otherwise = Queue lp1 (f ++ reverse r) [] > > emptyQ :: Queue a > emptyQ = Queue 1 [] [] > > snocQ :: Queue a -> a -> Queue a > snocQ (Queue lp1 f r) x = queue (lp1 + 1) f (x:r) > > toListQ :: Queue a -> [a] > toListQ (Queue _ f r) = f ++ reverse r > > initsQ :: [a] -> [[a]] > initsQ = map toListQ . scanl snocQ emptyQ > > > This implementation appears to take care of the performance wrinkle in > initsR and initsHO, while being only very slightly slower in other > contexts. It's longer, certainly, but it's not long. > > I have attached the Criterion report produced by the attached program > comparing initsR to initsQ. Previous tests definitively showed that > initsHO is a small constant factor worse than initsR, and > Data.List.inits is incomparably worse, so I limited this round to > initsR and initsQ. > > I therefore propose that we should replace the current implementation > of inits with initsQ, the queue-based one, unless someone comes up > with something faster and/or simpler very soon.

4 10

Polymorphism in the Prelude
by Richard Eisenberg 17 Aug '14

17 Aug '14

Hi libraries, Let me try to sum up the general sentiment I've seen: Having lots of polymorphism in the Prelude is great, but for two problems: 1) It's very confusing to novices. 2) In the case of using Control.Category definitions: kind-polymorphism is not portable I wish to ignore (2) for now, as it's a smaller concern given that it affects only a portion of the proposed changes. As a way to mitigate (1), I have been thinking of proposing something almost exactly along the lines of http://comments.gmane.org/gmane.comp.lang.haskell.glasgow.user/23719 (thanks for posting that link -- saved me from writing up the same thing!). But, after reading that thread, I tend to agree that tweaking the module system seems the wrong way to deal with helping novices. In designing my own libraries, my general guideline is to make the easy thing easy and make the hard thing only slightly less easy. Spurred on by Erik Hesselink's comment (http://www.haskell.org/pipermail/libraries/2014-June/023174.html) what if we just have two versions of `base` modules, the "normal" one that exports more monomorphic definitions (which novices are more likely to use) and a "Poly" one that exports more polymorphic definitions. For example: {{{ {-# LANGUAGE NoImplicitPrelude #-} import Prelude.Poly import Data.List.Poly import Data.Foldable import Control.Monad.Poly }}} and then it just works. Pros: - Not disruptive to current status quo. - No change in error messages for novices. - Can actually be implemented without *any* changes to `base` -- I could upload this solution to Hackage today. Cons: - Maintaining two copies of export lists. - Needs NoImplicitPrelude pragma. - Overhead of remembering which modules have a "Poly" version and which don't. - Somewhat ugly. Even as I write this, I'm not sure that this is at all a good idea. But, to me, it's really intriguing that the solution is achievable today, with no difficulty. I would wager that if these Poly modules were out in the wild today, we might all grumble at them, but I don't know if there would be a movement to change the Prelude. Richard

19 32

Maintenance release of haskell-cgi?
by John Alfred Nathanael Chee 15 Aug '14

15 Aug '14

Hackage trustees, haskell-cgi [1] doesn't build with ghc 7.8.3. Two pull requests exist on github [2,3] and the maintainer (cc'd) is unresponsive. Can someone do a proxy release of haskell-cgi? Thanks. [1] https://github.com/andersk/haskell-cgi [2] https://github.com/andersk/haskell-cgi/pull/7 [3] https://github.com/andersk/haskell-cgi/pull/6 -- Love in Jesus Christ, John Alfred Nathanael Chee http://www.biblegateway.com/ http://web.cecs.pdx.edu/~chee/

2 5