January 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

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

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

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

Re: RFC: include a cabal-install executable in future GHC releases
by Austin Seipp 23 Feb '14

23 Feb '14

Hello, My input is this: I think a lot of confusion stems from some documentation that just needs to be cleared up. I think that just cleaning up the pages so that: * http://www.haskell.org/cabal has binaries for Tier 1 platforms: OS X, Windows, FreeBSD i386/amd64, Linux i386/amd64. IMO, there should be a clear 'Download pre-built binaries' on the immediate front page that cannot be missed. * http://www.haskell.org/ghc/download still points to the platform for most users (i.e. the platform is more long-term stable/supported,) but also mentions cabal install binaries. They can be linked to directly from the subsection for each platform: "Download GHC 7.8.1 Mac OS X x86-64 - also download <latest cabal-install OS X build> from here" I personally think this would go a significant way to making it easier for people to bootstrap environments. (IMO, both the GHC and Cabal homepage could both do with a visual makeover as well, to make this all the more apparent and easily accessible.) As for cabal install binaries: I can easily provide dedicated hardware (thanks to Rackspace) for Windows, FreeBSD or Linux build machines. I also have a dedicated OS X machine in Oxford (thanks to Duncan) that can be used to build binaries for OS X as well. So I can absolutely provide resources for Cabal developers to build them if they'd like. At least for T1 platforms. As for shipping with GHC itself: this is technically possible, but slightly annoying to implement, and it also makes the build processes for a release slightly more annoying (which is mostly my problem.) But it is all doable. However, keep in mind I *do not* maintain the binary distributions for everything, nor do Cabal devs have access to all hardware - so all people making upstream releases for their platforms (i.e. Solaris, PowerPC, ARM/Linux, etc) must also package cabal themselves. But perhaps that's not a huge deal. I guess my vote on this is ultimately neutral. I think it can be fixed by simply making the downloads more clear. Alternatively we can package cabal-install. I'll leave the decision up to users at large and their votes. On Sun, Jan 26, 2014 at 7:08 AM, Daniil Frumin <difrumin(a)gmail.com> wrote: > cabal-install doesn't even have to be distributed in one tar.gz with > GHC, just merely mentioning cabal-install binaries on > http://www.haskell.org/ghc/download will surely help (assuming we get > to actually have the cabal-install binaries :) > > On Sat, Jan 25, 2014 at 10:48 PM, Gábor Lehel <glaebhoerl(a)gmail.com> wrote: >> +1 to this proposal. The benefits are obvious and practical: when installing >> a new GHC, it will save users the tedium of having to figure out how to >> build a cabal-install and then do so before they can install the packages >> they actually want. The drawbacks are indefinite and amorphous: the download >> is a little bit larger. So what? It further blurs the line between GHC and >> the Platform. Who does this harm? People who already have a cabal-install >> will now have a second one. What discomfort will this cause them? >> >> >> On Mon, Jan 20, 2014 at 1:02 AM, Carter Schonwald >> <carter.schonwald(a)gmail.com> wrote: >>> >>> 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 >>> >>> >>> >>> >>> _______________________________________________ >>> Glasgow-haskell-users mailing list >>> Glasgow-haskell-users(a)haskell.org >>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >>> >> >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users(a)haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> > > > > -- > Sincerely yours, > -- Daniil > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

4 3

incorrect MonadPlus law "v >> mzero = mzero"?
by Petr Pudlák 05 Feb '14

05 Feb '14

Hi, this law apparently fails for a MonadPlus instance that has more than one possible failure value. Consider: runIdentity . runErrorT $ ((ErrorT . Identity $ Left "failure") >> mzero :: ErrorT String Identity ()) evaluates to `Left "failure"`, which isn't equal to ErrorT's mzero `Left ""`. This isn't just the case of ErrorT, it fails for any MonadPlus with multiple failure values. For example lift (tell "foo") >> mzero :: MaybeT (Writer String) () is again distinct from mzero. Actually, no monad transformer with a MonadPlus instance can satisfy the law, because the first part in front of `>> mzero` can introduce side effects in the underlying monad. I'm not sure what should be the proper solution. Perhaps to change the laws to: return x >> mzero = mzero (v >> mzero) >>= f = (v >> mzero)` That is, if an expression ends with `mzero`, it behaves like `mzero`. Petr

3 6

Re: [Haskell-cafe] Unmaintained packages and hackage upload rights
by Carter Schonwald 30 Jan '14

30 Jan '14

I HAVE A SOLUTION for anyone who asks me, I will help manage the "this isn't maintained, i wanna take over maintership" pestering emails that need to happen. that said, you'll still need to email me to ask me to do that, or pester me on IRC as applicable. (which may take just as much time as "hey i'd like to take over maintainership of X on hackage please" sent to the libraries list) Point being, if someone finds the prospect of doing the pestering needed to do the process overwhelming, ask me nicely, and i'll try to help push it along (while keeping them in CC and such, though they of course will have to chime in at some point) should this thread also touch on the the libraries mailing list? ccing it just in case :) point being, we need to have a responsive, *responsible* way of quickly resolving these things that easy to do. time for comments: 2 weeks -Carter On Thu, Jan 30, 2014 at 11:53 AM, Ben Gamari <bgamari.foss(a)gmail.com> wrote: > Clark Gaebel <cgaebel(a)uwaterloo.ca> writes: > > > How does the process of taking over maintenance add latency to your work? > > > > 1) Check out broken version of package. > > 2) Fix locally, bump version number locally. > > 3) cabal sandbox add-source ../fixed-package in any package that needs > the > > fixed version. > > 4) Email hackage admins for upload rights. > > 5) Continue working on your actual project. > > 6) Receive upload privileges one day. > > 7) Upload fixed package. > > > > As far as I can tell, the only real latency cost here is that paid to fix > > the broken version. > > > In my experience, step 4 involved several round trips between a number > of different people. Admittedly, this is in part because it's easy to > forget about the broken package after you have fixed it locally. > > Cheers, > > - Ben > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > >

1 0

[Proposal] Add default implementation of mappend/mempty in terms of mconcat
by Niklas Haas 27 Jan '14

27 Jan '14

Hello, I noticed that the current Monoid class doesn't actually provide default implementations of mappend/mempty in terms of mconcat, even though this is technically very simple: > mempty = mconcat [] > mappend a b = mconcat [a, b] This would be a rather small and non-invasive change that shouldn't break any existing programs. The main downside is that an empty Monoid declaration would produce no warnings, but #7633 gives us the ability to solve this. Discussion period: 2 weeks

8 8