- Libraries - Haskell.org

Re: [commit: unix] master: change notes (1461d21)
by Ian Lynagh 23 Aug '13

23 Aug '13

On Fri, Feb 08, 2013 at 01:56:28PM +0000, Simon Marlow wrote: > On 03/02/13 20:48, Simon Marlow wrote: > >On 02/02/13 14:11, Ian Lynagh wrote: > >> > >>The unix version number is still 2.6.1.0, but doesn't the new policy > >>http://hackage.haskell.org/trac/ghc/wiki/Repositories#Modifyinglocalpackages > >> > >>mean that it should be bumped to 2.7.0.0 now? Actually, having just tried to do this, I'm not sure how it's meant to work in practice. Bumping unix's version requires relaxing the dependencies in Cabal and haskeline on unix. One way to do this is to get upstream to relax the dependency and updating our lagging repo. That will mean a version of the library will be uploaded to hackage with the relaxed dependency. But we don't know what the release 2.7.0.0 of unix will look like yet; perhaps by the time it is released it will not work with the current Cabal/haskeline code. The other way is to make local ghc-only changes to relax the dependencies, but that would increase the risk that we'd release with a ghc branch of the library by mistake. Wouldn't it be better to go back to the previous scheme, where we didn't update version numbers until release time? Thanks Ian

5 7

backwards compatibility of array
by Richard Eisenberg 20 Aug '13

20 Aug '13

The following thread on Haskell-cafe is of interest to this list: http://www.haskell.org/pipermail/haskell-cafe/2013-August/108427.html The first email introduces an infelicity in the libraries, but then the discussion says that this address (libraries(a)haskell.org) is listed as the maintainer of the libraries, and yet the mailing list cannot be written to by the general public. I tend to agree that this should be fixed. Richard

2 1

RE: isSafeOverlap
by Simon Peyton-Jones 20 Aug '13

20 Aug '13

| Oh also, we deprecated a bunch of unsafe functions in modules. For | example, `unsafeInterleaveST` in Control.Monad.ST.Lazy as it was moved | to Control.Monad.ST.Lazy.Unsafe. | | Are you happy with me removing these now that it's been a three | releases (7.2, 7.4, 7.6) with them deprecated? Ccing 'libraries' but yes that sounds reasonable. Simon | -----Original Message----- | From: David Terei [mailto:davidterei@gmail.com] | Sent: 20 August 2013 00:04 | To: Simon Peyton-Jones | Subject: Re: isSafeOverlap | | Oh also, we deprecated a bunch of unsafe functions in modules. For | example, `unsafeInterleaveST` in Control.Monad.ST.Lazy as it was moved | to Control.Monad.ST.Lazy.Unsafe. | | Are you happy with me removing these now that it's been a three | releases (7.2, 7.4, 7.6) with them deprecated? | | Cheers, | David | | On 19 August 2013 13:04, David Terei <davidterei(a)gmail.com> wrote: | > Sure. Doing right now. | > | > On 19 August 2013 01:19, Simon Peyton-Jones <simonpj(a)microsoft.com> | wrote: | >> David | >> | >> Looking at BasicTypes.lhs I see that the OverlapFlag has an | isSafeOverlap | >> field for every flag. I guess this is something to do with Safe | Haskell but | >> there is nothing to say so, nor any comment to explain what the | significance | >> is. | >> | >> Do you think you might add "Note [isSafeOverlap flag]" to explain? | Thanks! | >> | >> Simon | >> | >> | >> | >> Microsoft Research Limited (company number 03369488) is registered in | >> England and Wales | >> | >> Registered office is at 21 Station Road, Cambridge, CB1 2FB | >> | >>

2 2

suggestion: use lazy pattern matching for Monoid instances of tuples
by Petr Pudlák 19 Aug '13

19 Aug '13

Dear haskellers, currently the instances are defined as |instance (Monoid a,Monoid b) =>Monoid (a,b)where mempty = (mempty, mempty) (a1,b1) `mappend` (a2,b2) = (a1 `mappend` a2, b1 `mappend` b2)| However for some applications this isn't lazy enough, for example |-- | Build two lists by folding on a pair of `Endo` monoids. test = head $ appEndo (fst $ foldMap (f &&& f) [1..]) [] where f =Endo . (:)| never terminates because of the unnecessary pattern matching on the constructor |(,)| forces evaluation of the whole infinite list. I suggest to change all Monoid instances for tuples to be like | instance (Monoid a,Monoid b) =>Monoid (a,b)where mempty = (mempty, mempty) ~(a1,b1) `mappend` ~(a2,b2) = (a1 `mappend` a2, b1 `mappend` b2) -- ^^^ ^^^| which fixes the problem. Best regards, Petr

7 14

Proposal: Add gtraverse to Data.Data
by Edward Kmett 18 Aug '13

18 Aug '13

Data.Data provides an gmapM as an analogue to mapM but not one to traverse. The following definition from lens fills in this gap, but it probably belongs in Data.Data alongside its kin. gtraverse :: (Applicative f, Data a) => (forall d. Data d => d -> f d) -> a -> f a gtraverse f = gfoldl (\x y -> x <*> f y) pure Discussion period: 2 weeks -Edward Kmett

3 2

Proposal: Non-allocating way to iterate over a Data.Map: traverseWithKey_
by Ryan Newton 16 Aug '13

16 Aug '13

If there's not an existing way to do this, I suppose this is a minor proposal. When writing monadic code that consumes a container (Set, Map) etc, I often find that I just want what iterators in imperative languages provide: that is, to iterate over the contents of a large container, performing monadic effects along the way, but without allocating. The Foldable instance for Data.Map almost gives you what you want, but it only exposes the values, not their keys. The "traverseWithKey" function is close too, but it builds a new Map as output: traverseWithKey :: Applicative<../base-4.6.0.1/Control-Applicative.html#t:Applicative> t => (k -> a -> t b) -> Map <Data-Map-Lazy.html#t:Map> k a -> t (Map<Data-Map-Lazy.html#t:Map> k b) So in practice what I do, and what I assume others do is this: mapM_ f (toList myMap) And I don't see any fusion rules that would ameliorate this (they seem limited to pure code), so I'm betting I always pay the cost of conversion to a list. In the case of Data.Map* the proposal is simply a "traverseWithKey_" that returns "t ()".* This follows the suffixing convention of mapM/mapM_ etc. More generally, it would be nice to do an audit of all popular containers with the assumption of very large collections that cant' be frivolously copied. -Ryan P.S. Actually, there are a number of places where the standard libraries could do with a more complete set of "_" functions -- e.g. it always chafes to not have "atomicModifyIORef_", which would apply a (a->a) function like a regular modifyIORef.

10 42

Proposal to solve the `EitherT` problem.
by Gabriel Gonzalez 15 Aug '13

15 Aug '13

As an application writer I'm a big fan of Edward's `either` package because his `EitherT` does not require an `Error` constraint. As a library writer, I am wary of heavy dependencies and I would prefer something more light-weight that I can depend on. Normally I would just directly contact Edward about reducing the number of dependencies but there was a previous discussion here about possibly merging his work into `transformers`, so I'm renewing that discussion and bringing up a few approaches for consideration. 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. * 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. * Approach 3: Convince Edward to reduce the dependencies of the `either` package and submit the simplified version to the Haskell platform. Disadvantage: One extra import instead of just importing `transformers`. * Approach 4: None of the above. Disadvantage: Packages that depend on `either` have very low prospects of making it into the Haskell platform. If you have time, just take a moment to vote on which approach you favor or propose another alternative if you have another idea that I haven't listed.

17 36

(no subject)
by Gabriel Gonzalez 14 Aug '13

14 Aug '13

> My preference is to call the new transformer ExceptT, with a basic monad called Except, in line with most of the other transformers, and to deprecate ErrorT. (The rationale for the name is that Either isn't just for exceptions, and exceptions aren't just for errors.) Specializing to an identity base monad is usually a misfeature in real code and only useful for pedagogical purposes. Experts leave it polymorphic like this: expertCode :: (Monad m) => EitherT E m R By designing the API entirely around the identity specialization you're optimizing for a narrow skill range of intermediate Haskell programmers who are: a) Smart enough to figure out that `ExceptT` is the official generalization of `EitherT` b) Not smart enough to figure out how to keep the base monad polymorphic So I propose that you leave the monad transformer name as `EitherT`, but use `Except` for the `Identity` specialization: type Except e r = EitherT e Identity r This has the nice properties that: * The identity specialization doesn't conflict with `Either` * Beginners find `transformers` when they search for `EitherT` as they inevitably will * Existing packages that use `EitherT` won't break, thus preserving compatibility with the code bases that Edwards already mentioned

4 5

Void type in base
by Shachaf Ben-Kiki 13 Aug '13

13 Aug '13

It seems strange that there's a canonical unit type -- () -- which is used extensively, but no canonical type for its dual, the uninhabited type. The closest we have is in Edward Kmett's void package, but several people seem to prefer to write it themselves rather than incur an extra dependency, which is a shame. The proposal is just to copy the Data.Void API into base: data Void -- EmptyDataDecls is in Haskell 2010 absurd :: Void -> a vacuous :: Functor f => f Void -> f a -- instances for Typeable, Data, Generic, Eq, Ord, Show, Read, Ix, Exception (void also has a vacuousM for Monad, but since Functor will probably become a superclass, it might not be necessary to export it... By default it probably makes sense to include it, though.) void could then re-export Data.Void so packages that depend on it will keep working. ("void" also has unsafe functions -- namely unsafeVacuous, which isn't safe with an invalid Functor instance -- but those probably don't belong in base.) hashable and semigroups would also need to be updated to add their respective instances as non-orphans. The instances should probably be made compatible with void's. In particular note that void's Eq instance has `_ == _ = True`. Discussion period: 2 weeks. Shachaf

11 17

Workflow for maintaining Haskell platform packages
by Sven Panne 12 Aug '13

12 Aug '13

Currently I'm trying to pick up my work on the OpenGL-related packages again, and while doing that, I came across some organizational difficulties: The GLUT/OpenGL/OpenGLRaw/GLURaw packages are now part of the Haskell platform (thanks to Jason and others, this is really great!), and they depend on each other, e.g. GLUT => OpenGL => OpenGLRaw. So my question is: What is the recommended workflow to easily maintain/extend packages contained in the Haskell platform? I want to be able to quickly go back to the distributed package versions, OTOH I want to relatively quickly try out new things, extend APIs, etc. for the upcoming new versions of those packages. Any hints how to do that are highly appreciated. Cheers, S.

4 9