May 2012 - Libraries - Haskell.org

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

A more useful Monoid instance for Data.Map
by Daniel Peebles 13 Mar '13

13 Mar '13

Hi all, Currently Data.Map has a Monoid instance, but it's rather lossy and not as general as it could be: instance (Ord k) => Monoid (Map k v) where mempty = empty mappend = union mconcat = unions The instance would be much nicer if it required a Monoid on v and used unionWith mappend instead of just union. The current behavior could be emulated by using First/Last as the Monoid (or ideally a semigroup, but that's or another discussion), but other more interesting Monoid instances could also be used for the values. I realize that changing instances could break code, but I'd be curious to see how many people even use the current monoid instance. Does anyone have any system for testing hypotheses like this (by typechecking a large randomized chunk of hackage or something)? It looks like the idea has been around for at least five years: http://hackage.haskell.org/trac/ghc/ticket/1460 but the proposal was abandoned, so I wanted to see if I could get people to start talking about it again. Thanks, Dan

13 29

Changes to Typeable
by Simon Peyton-Jones 26 Nov '12

26 Nov '12

Friends (Ian pointed out that I should have sent this to the libraries list): The page describes an improved implementation of the Typeable class, making use of polymorphic kinds. Technically it is straightforward, but it represents a non-backward-compatible change to a widely used library, so we need to make a plan for the transition. http://hackage.haskell.org/trac/ghc/wiki/GhcKinds/PolyTypeable Comments? You can fix typos or add issues directly in the wiki page, or discuss by email Simon

25 54

Proposal: unsnoc, unsafeInit and unsafeLast for the bytestring library
by Mikhail Vorozhtsov 28 Aug '12

28 Aug '12

Hi. I propose to add the missing counterparts of `uncons` and `unsafeHead/Tail` functions to the bytestring library. Discussion deadline: 2 weeks The patch is attached.

5 10

Proposal: add Functor instance to Control.Exception.Handler
by Patrick Palka 03 Jul '12

03 Jul '12

A Functor instance for Handler could be useful: e.g. foo :: IO (Maybe a) handlers :: [Handler ()] foo `catches` map (Nothing <$) handlers Proposed instance definition: instance Functor Handler where fmap f (Handler h) = Handler (fmap f . h) Deadline: 2 weeks

2 2

Unboxed Vectors of newtype'd values
by Ben Gamari 06 Jun '12

06 Jun '12

One of the reasons I find Haskell so well suited to my work is its ability to easily work with large quantities of data. In particular, I find myself using Data.Vector.Unbox quite frequently. Another of my reasons for using Haskell is the type safety it provides. I find myself using newtypes very frequently to force myself to think about invariants that a more weakly typed language would allow me to simply ignore. Sadly, these two features don't interact particularly well. While the Data.Vector.Unbox documentation claims that "Implementing unboxed vectors for new data types can be very easy", it then goes on to list an abridged version of the Complex instance---dozens of lines of code. While this code certainly isn't difficult to write, it is time consuming, error-prone, and, above else, utterly mind deadeningly dull (making it quite uncharacteristic for Haskell). So dull that I generally avoid newtypes at all cost in code that might need to use unboxed vectors. This boilerplate is largely due to Vector's use of type families as this precludes the use of (the otherwise quite cunning) GeneralizedNewtypeDeriving to automatically derive the necessary instances. What can be done to fix this unfortunate state of affairs? The obvious solution here seems to be Template Haskell, but this seems a bit of an unfortunate hack around what might be a deficiency in the type families mechanism (or at least this application of it). The newtype package provides a nice mechanism to pack and unpack newtypes, but providing blanket Unbox instances for Newtype instances seems like an awful idea (and, frankly, I'm not sure how this would work with type families). Other than these two possibilities I am at a loss. Thoughts? I'd appreciate any ideas folks could offer. Cheers, - Ben

10 26

Re: [Haskell] Types of when and unless in Control.Monad
by Ivan Lazar Miljenovic 05 Jun '12

05 Jun '12

On 22 April 2012 21:39, Christian Höner zu Siederdissen <choener(a)tbi.univie.ac.at> wrote: > * Julian Gilbey <julian(a)d-and-j.net> [22.04.2012 09:22]: >> On Sat, Apr 21, 2012 at 08:28:27PM -0500, Strake wrote: >> > On 21/04/2012, Andreas Abel <andreas.abel(a)ifi.lmu.de> wrote: >> > > to avoid silly "return ()" statements like in >> > > >> > > when cond $ do >> > > monadicComputationWhoseResultIWantToDiscard >> > > return () >> > >> > (when cond ∘ void) monadicComputationWhoseResultIWantToDiscard >> > or >> > when cond $ () <$ monadicComputationWhoseResultIWantToDiscard >> >> How is that simpler than >> >> when cond monadicComputationWhoseResultIWantToDiscard >> >> which it would be with the suggested new type? >> >> Julian > > Wouldn't "when_" and "unless_" or similar be better? I'd probably like > to have the compiler annoy me, since it is not clear that I want to > discard the result. If I really want to discard, I should have to make > it clear as there is probably a good reason for the inner function to > return a result in the first place? Agreed; I'm not sure if I agree with having such functionality (Henning makes some good points), but if people deem it desirable then I think it would be better to have them with new names for the reasons you state. -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com http://IvanMiljenovic.wordpress.com

4 7

Fix risk of dead-lock in documentation of Control.Concurrent
by Bas van Dijk 27 May '12

27 May '12

The current documentation of Control.Concurrent proposes a function to wait for a child thread to complete: myForkIO :: IO () -> IO (MVar ()) myForkIO io = do mvar <- newEmptyMVar forkIO (io `finally` putMVar mvar ()) return mvar This function has the risk of causing a dead-lock. If an asynchronous exception if thrown before the putMVar exception handler is installed the mvar will remain empty. This causes a dead-lock when the mvar is taken. The patch attached to the ticket [6126] fixes this problem by correctly masking asynchronous exceptions before forking. Also, instead of returning the mvar it returns a computation that waits for the child thread to complete. This is safer than returning the mvar itself since a user can't accidentally put the mvar (which will dead-lock) or take the mvar (which when executed twice will dead-lock). The attached patch additionally rewrites the function to wait for a group of threads to complete. Instead of keeping a list of MVars, I use a counter (stored in a TVar) that counts the number of running threads. The counter is incremented when a thread if forked and decremented when it completes. Waiting for the group of threads to complete is accomplished by checking if the counter has reached 0 and if not retry the transaction. Regards, Bas [6126] http://hackage.haskell.org/trac/ghc/ticket/6126

1 0

Intersect by and union documentation in base
by Bram Neijt 27 May '12

27 May '12

Dear library maintainers, I've used both intersectBy and unionBy from the Base.List module. For intersectBy the documentation did not mention which element will be used when an element is in both lists. The attached patch adds a line to the documentation of intersectBy, where I think it makes sense to add this information. The unionBy documentaiton has the same kind of problem, however I did not patch that because I'm not sure whether this is part of the contract union whats to take on (I mean being deterministic in which list is the preferred source of elements). Please consider updating the documentation and feel free to contact me for more information if needed. Greetings, Bram

2 1

[PATCH] Fix typo in documentation of GHC.Exts.groupWith
by Simon Hengel 27 May '12

27 May '12

--- GHC/Exts.hs | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/GHC/Exts.hs b/GHC/Exts.hs index 0bf8f7f..8281895 100755 --- a/GHC/Exts.hs +++ b/GHC/Exts.hs @@ -102,7 +102,7 @@ sortWith :: Ord b => (a -> b) -> [a] -> [a] sortWith f = sortBy (\x y -> compare (f x) (f y)) -- | The 'groupWith' function uses the user supplied function which --- projects an element out of every list element in order to to first sort the +-- projects an element out of every list element in order to first sort the -- input list and then to form groups by equality on these projected elements {-# INLINE groupWith #-} groupWith :: Ord b => (a -> b) -> [a] -> [[a]] -- 1.7.5.4

2 1