June 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

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 17 Sep '14

17 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

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

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

Proposal: Use (.) and id from Control.Category in Prelude
by Carter Charbonneau 21 Jul '14

21 Jul '14

(.) and id are generalized in the Category class in Control.Category. In the past, many libraries have instructed users to use (.) and id from Control.Category for composition of their types. Importing these types into Prelude shouldn't break existing code, and makes libraries that use Category easier to use. Discussion period: 4 weeks

12 15

Re: Add instances for Functor, Monad, Applicative to Data.Monoid.First, Last
by Ben Gamari 20 Jul '14

20 Jul '14

Edward Kmett wrote, > I'd say we should just act upon it. At this point what it needs is a patch. > You mean like this one against GHC master? Cheers, - Ben

2 3

Re: [Haskell-cafe] Requesting maintainership: bzlib-conduit and process-conduit
by Michael Snoyman 29 Jun '14

29 Jun '14

Oops, you're right. I've added libraries@ to the CC list. On Sun, Jun 29, 2014 at 7:12 PM, Mateusz Kowalczyk <fuuzetsu(a)fuuzetsu.co.uk> wrote: > On 06/29/2014 06:02 PM, Michael Snoyman wrote: > > I'd like to request to be granted maintainership of two conduit-related > > packages: bzlib-conduit and process-conduit. Both packages are maintained > > by the same author. I opened up a pull request[1] on bzlib-conduit back > in > > January, and haven't heard back yet. There's also an issue with > > process-conduit[2] which I'd like to address, but given the lack of > > response of bzlib-conduit, haven't sent a pull request yet. > > > > I also emailed the author directly five days ago regarding the > > bzlib-conduit pull request, and have not received a response. > > > > [1] https://github.com/tanakh/bzlib-conduit/pull/7 > > [2] https://github.com/tanakh/process-conduit/issues/14 > > > > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe(a)haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > Two things: > > 1. Does this not need to go on libraries@ instead? > 2. I happen to know the author is an active Twitter user under the > ‘tanakh’. I will tweet him your e-mail but perhaps it's worth trying > that method of communication too. > > -- > Mateusz K. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >

1 0