- Libraries - Haskell.org

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

Re: exceptions API (Was: deprecating Error class, which Was: Proposal: add handleError to mtl))
by Edward Kmett 06 Jun '13

06 Jun '13

On a somewhat related note, I've started but not yet released an 'exceptions' package based on some work from Mark Lentczner, after he encouraged me to explore the design space with an eye towards inclusion in the platform because some packages like CGI need something like MonadCatchIO-transformers, but GHC HEAD removed block and unblock, so the MonadCatchIO-transformers API is broken. It doesn't fall into the scope of the mtl as it relies on the extensible exceptions mechanism and so needs ExistentialQuantification, but it provides a generalization of the Control.Exception API that lifts it over monad transformers along with a pure untagged exception-handling monad. https://github.com/ekmett/exceptions I was going to sound folks out about what improvements they wanted to see in the API over this weekend at Hac Phi, but I suppose I can throw that out to the larger libraries list as well, given the current discussion. The haddocks for the development version are available here: file://localhost/Users/ekmett/haskell/exceptions/docs/Control-Monad-Catch.html -Edward On Thu, Jun 6, 2013 at 7:00 AM, Henning Thielemann < lemming(a)henning-thielemann.de> wrote: > > On Thu, 6 Jun 2013, Roman Cheplyaka wrote: > > * Henning Thielemann <lemming(a)henning-thielemann.de**> [2013-06-06 >> 12:14:10+0200] >> >>> >>> On Wed, 5 Jun 2013, Ross Paterson wrote: >>> >>> On the subject of ErrorT, I wonder if it's time to deprecate the Error >>>> class. >>>> >>> >>> Since I think ErrorT gives the wrong association with the 'error' >>> function, I would prefer to give up the Control.Monad.Trans.Error >>> module entirely and start a new module Control.Monad.Trans.Exception. >>> >> >> ... which would give the wrong association with exceptions (in the >> Control.Exception sense). I don't see how this is an improvement. >> > > It's the better association and it is already mentioned in the module > description of Control.Monad.Trans.Error: > > "This monad transformer adds the ability to fail or throw exceptions to a > monad." > > Nonetheless, you may suggest another module name. Independent from the > name of a new module, I would suggest to deprecate the Error name instead > of removing something from the Error module. > > > ______________________________**_________________ > Libraries mailing list > Libraries(a)haskell.org > http://www.haskell.org/**mailman/listinfo/libraries<http://www.haskell.org/mailman/listinfo/libraries> >

4 4

Proposal: add handleError to mtl
by Erik de Castro Lopo 06 Jun '13

06 Jun '13

Hi all, I would like to propose the following convenience function (with implementation) for the mtl library: handleError :: MonadError e m => (e -> m a) -> m a -> m a handleError = flip catchError which follows the handle function from Control.Exception.Base: handle :: Exception e => (e -> IO a) -> IO a -> IO a Like the handle function, handleError allows the handling of exceptions to be expressed in a more natural way, turning: catchError ( do mumble something mumble ) handler into: handlerError handler $ do mumble something mumble -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

5 5

doesFileExist and doesDirectoryExist overly verbose?
by harry 05 Jun '13

05 Jun '13

doesFileExist and doesDirectoryExist seem overly verbose - wouldn't fileExists and directoryExists be better? Not a major issue, but easily fixed. -- View this message in context: http://haskell.1045720.n5.nabble.com/doesFileExist-and-doesDirectoryExist-o… Sent from the Haskell - Libraries mailing list archive at Nabble.com.

4 5