June 2013 - Libraries

2014 Applicative => Monad proposal
by David Luposchainsky 21 Jun '13

21 Jun '13

Hello libraries, it's on! Time to tackle the Applicative-Monad issue, hopefully once and for all. Over the last couple of weeks I've looked through previous proposals, asked #haskell about their opinions, and compiled it all into one file that sums up what I made of that. It's a bit long for an email and uses markdown, so I'll just provide links at the end of this mail instead of pasting it in here. In there, the whole thing and how to approach it is explained in more detail. Here's an abstract of what it the proposal consists of: - Don't break compatibility - Apply it gently - Applicative m => Monad m - Applicative into Prelude (and therefore into the Report) - (Alternative m, Monad m) => MonadPlus m - Promote `join` into the Monad typeclass Let's make this happen! I'm going to give a ballpark discussion period of four weeks, but since I can imagine this discussion could become quite complex we shouldn't take it too serious. I'll summarize what's been going on periodically though. David Links: The proposal text on Github (link fixed, sorry for the deadlink yesterday): https://github.com/quchen/articles/blob/master/applicative_monad.md (This file is subject to changes, depending on how this discussion goes. I'll try to make it reflect the current consensus.) And just in case Github silentbans me again for submitting too many edits to my Gist (grrr), here's a copy of the file on HPaste as backup: http://hpaste.org/88423

32 52

Re: Proposal to solve the `EitherT` problem.
by Gabriel Gonzalez 19 Jun '13

19 Jun '13

> > Fair point, but then EitherT is too neutral, giving no hint of the purpose > of the monad instance, and suggesting a symmetry that is absent from the > monad: Right is normal monadic sequencing, while Left is the exceptional > control path. Things get particularly 'sinister' when you get to naming > the throw and catch combinators. It's a bit like the reason for having > Writer instead of using the monad instance for (,). So I'd lean more to > something like Except, which would also be in line with Moggi's original > presentation of this monat and transformer. However, there is prior art (i.e. the existing name of `Either`). Using a different name for the monad and the monad transformer seems like bad form to me. This is also a good argument for keeping both monad transformers in `transformers`. `ErrorT` satisfies the people who want a meaningful name and `EitherT` satisfies the people who prefer a neutral purpose. > I also think that the monad instances on Either and (,) are abuses. (And the monad instance on (->), too, since once I got a hard to find error where a missing argument in a function call was interpreted as an instance of the Reader monad.) I think that this position is too extreme. The use of the `Either` monad for error handling is Haskell canon and is more widely understood than even monad transformers. The logical conclusion of what you are proposing is to duplicate all `Either` machinery once for each potential application of `Either`. That's not to say that there shouldn't be isomorphic types with names and behaviors tailored to specific application domains. I understand the perils of "boolean blindness" (and its equivalent for other types). However, there needs to be space in the standard libraries for the neutral approach otherwise you will fragment the library ecosystem considerably.

3 2

Re: Proposal to solve the `EitherT` problem.
by Gabriel Gonzalez 17 Jun '13

17 Jun '13

> > On Sun, Jun 16, 2013 at 02:52:46PM -0700, Gabriel Gonzalez wrote: > > There are three approaches that I'd like to submit for consideration > > and receive feedback on: > > > > * Approach 1: Remove the `Error` constraint from `transformers` > > > > Disadvantage: This silently breaks all existing uses of `fail`. I > > don't know any way to add a compiler warning to notify downstream > > libraries of this change. > I'm in favour of this one. We can catch some of these uses by deprecating > the Error class, as the only predefined instances are for IOException > and String. I'm going to add another disadvantage of this approach: `ErrorT` is not as good of a name. `EitherT` is a more neutral name, which matters if you want to use it for non-error-based flow control like the way I describe here: http://www.haskellforall.com/2012/07/breaking-from-loop.html > > > * Approach 2: Add `EitherT` to `transformers` alongside `ErrorT` and > > have them both implement `MonadError`. > > > > Disadvantage: Bloat from having two almost identical monad > > transformers. However, there is precedent from duplicating > > `StateT`, `WriterT` and `RWST` for both strict and lazy instances. > Those is at least a rationale for two StateT transformers with strict > and lazy instances. (Since the strict WriterT doesn't achieve its aim, > I'm in favour of deprecating it, and the strict RWST.) The nice thing about Approach 2 is that it is backwards compatible for now and gives downstream libraries a chance to gracefully transition to `EitherT` if you decide to deprecate `ErrorT`. This works out better than usual because the names are different so they can peacefully coexist for one release. However, you might still want to keep `ErrorT` around as long as `fail` is still part of the `Monad` class.

3 2

Cabal dependency extrema testing
by Bram Neijt 16 Jun '13

16 Jun '13

Hi all, I think it would be interesting to test build a package with the "latest" and "oldest" allowed dependencies, to see if the dependency boundaries hold. For example, build the text[1] package with version 0.2 of test-framework-hunit (oldest allowed according to .cabal file) to see if that is still works. Does anybody know of previous work on that? Does anybody have pointers on how to build with a specific version set? What is the easiest way to parse the dependencies in the cabal file, API pointers are also very much appreciated :) Greetings, Bram [1] http://hackage.haskell.org/packages/archive/text/0.11.2.3/text.cabal

4 10

Re: stm: newBroadcastTChan and friends (a proposal, and a question)
by wren ng thornton 16 Jun '13

16 Jun '13

On 5/13/13 1:24 AM, wren ng thornton wrote: > PROPOSAL: I propose changing newBroadcastTChanIO to match > newBroadcastTChan. (Deadline: 2 weeks) ACCEPTED: +1: wren ng thornton, Edward Kmett, John Wiegley; -1: noone. http://www.haskell.org/pipermail/libraries/2013-May/019808.html http://hackage.haskell.org/trac/ghc/ticket/7986 -- Live well, ~wren

1 0

Re: Proposal: Warn when using Enum instance of Float or Double
by wren ng thornton 16 Jun '13

16 Jun '13

On 6/16/13 3:26 AM, harry wrote: > The Enum instances for Float and Double have dubious semantics which cause > endless confusion, e.g. > http://stackoverflow.com/questions/13203471/the-math-behind-1-0999999999999…, > http://stackoverflow.com/questions/9810002/floating-point-list-generator, > http://stackoverflow.com/questions/7290438/haskell-ranges-and-floats, > http://stackoverflow.com/questions/10328435/how-to-solve-floating-point-num…, > and many more. > > I would therefore like to propose that the usage of an Enum instance of > Float or Double generate a compiler warning, such as "The Enum instance of > Float is subject to rounding errors". Deadline: 2 weeks. +1. > Pedantic question: Should it be the Enum instance _of_ Float or _for_ Float? "for". -- Live well, ~wren

1 0

Why is there no Foldable instance for Either?
by Gabriel Gonzalez 13 Jun '13

13 Jun '13

I'm surprised that `Either` does not have a `Foldable` instance of the form: import Data.Foldable import Data.Monoid instance Foldable (Either e) where foldMap f (Left _) = mempty foldMap f (Right r) = f r foldr _ z (Left _) = z foldr f z (Right r) = f r z In other words, the above instance would behave like the `Maybe` `Foldable` instance, treating `Left` in the same way as `Nothing`. This came up in the context of an issue raised on the `errors` package: https://github.com/Gabriel439/Haskell-Errors-Library/issues/16 I could provide an orphan instance for `Either` in the `errors` package, but I wanted to ask if it was possible to incorporate the instance directly into `Data.Foldable`.

10 15

Fwd: Proposal: Add Data.Semigroup to base, as a superclass of Monoid
by Gabriel Gonzalez 13 Jun '13

13 Jun '13

Forgot to copy `libraries` on my answer to your question: On Wed, Jun 12, 2013 at 3:28 AM, Herbert Valerio Riedel <hvr(a)gnu.org> wrote: > On 2013-06-12 at 00:04:04 +0200, Gabriel Gonzalez wrote: > > I think types that lack an empty element are a misfeature. > > ...so having a data-type for representing non-empty lists (on which > operation such as head/last/minimum/maximum et. al can be proper > statically guaranteed total functions as opposed to resorting to > 'Maybe'-wrapped results which need to be checked dynamically at runtime) > is a misfeature? > > I phrased that poorly. Non-empty data types are useful, but having a combining operation on those types of type: A -> A -> A ... is not. The very example you gave (non-empty lists) shows why. If you combine two non-empty lists you can actually prove a stronger result, that the combined list has at least two elements. However, you lose that information if you use the `mappend` operation. I'm not saying that non-empty lists shouldn't have a combining operation, but rather that `mappend` is not the appropriate operation for the task. > They usually end up contaminating everything they touch, which is why > > semigroups forms an entire parallel ecosystem of its own. > > Can you provide a concrete example showing the kind of problematic > "contamination" that is caused by semigroup-forming types? > > The non-empty list example shows what I meant. The moment you start including extra information like non-emptiness you have to re-engineer all downstream operations to preserve that information as faithfully as possible. Again, there's nothing wrong with that, but it's not deserving of its own type class or a special place in the Prelude. > cheers, > hvr >

5 5

Re: Proposal: Add Data.Semigroup to base, as a superclass of Monoid
by Gabriel Gonzalez 12 Jun '13

12 Jun '13

-1 I think types that lack an empty element are a misfeature. They usually end up contaminating everything they touch, which is why semigroups forms an entire parallel ecosystem of its own. This is a very slippery slope that won't end with the addition of `Data.Semigroup` and once it is in it will be impossible to take it out.

2 1

suggestion: A common type class for mutable variables
by Petr Pudlák 10 Jun '13

10 Jun '13

Dear Haskellers, I noticed that there is no common typeclass that would unify STRefs and IORefs. We already have MArray for ST(U)Arrays and IO(U)Arrays, so why not for references as well? This would allow writing generic code that can use both ST- and IO-based variables. I've found that there is a package that provides such a type class: http://hackage.haskell.org/package/reference I'd suggest to add similar functionality to base, perhaps with some different wording - I'd rather use Data.MRef (as "mutable reference"). If there is some interest in it, I'd prepare a concrete code for consideration. Best regards, Petr Pudlak

6 17