- Libraries - Haskell.org

PROPOSAL: re-export 'Typeable' type-class from Prelude
by Herbert Valerio Riedel 12 Sep '14

12 Sep '14

TL;DR ===== Re-export 'Data.Typeable.Typeable' from 'Prelude' Motivation ========== Since GHC 7.8 the ubiquitous 'Typeable' instances can only be auto-derived via `... deriving Typeable`, moreover there's a new extension `-XAutoDeriveTypeable` which implicitly auto-derives 'Typeable' for all defined types in modules for which that extension is enabled. However, even if you enable `-XAutoDeriveTypeable` you still need to explicitly bring the 'Typeable' class into scope, with e.g. import Data.Typeable (Typeable) otherwise GHC complains with Not in scope: type constructor or class ‘Typeable’ Since at this point it's become current practice to have 'Typeable' instances for most types, it would be beneficial to save an 'import Data.Typeable (Typeable)' line for the sole purpose of deriving such instances. By having 'Prelude' re-export 'Typeable' from GHC 7.10 on (should this proposal be implemented) it would suffice to have a default-extensions: -XAutoDeriveTypeable` in the Cabal file and have 'Typeable' instance auto-derived for all types defined in a package w/o any source changes (unless there's a name-clash with 'Typeable') Discussion period ================= The usual 2 weeks

11 13

Taking over random-fu
by Dominic Steinitz 12 Sep '14

12 Sep '14

Hi James, I have quite a few changes I would like to make to the package and I haven’t heard anything from you. I think they are all for the good. This > http://www.haskell.org/haskellwiki/Taking_over_a_package suggests you can add me as a maintainer by going to > http://hackage.haskell.org/package/random-fu/maintainers/ and clicking on edit. I am DominicSteinitz on hackage. Also you would have to give me permission to update the repo on github where I am idontgetoutmuch. Many thanks, Dominic Steinitz dominic(a)steinitz.org http://idontgetoutmuch.wordpress.com

1 0

HTTP package - supported GHC versions
by Ganesh Sittampalam 11 Sep '14

11 Sep '14

Hi, The HTTP package supports a whole load of old GHCs - the current version should actually work with GHC 6.10. For future releases I plan to drop most of these. Any opinions about how far back it should support? I'm thinking restricting it to either 7.4+ or 7.6+, but I'm open to keeping support for older versions too if there's a real need. Cheers, Ganesh

6 13

Re: bedandbreakfast needing a release
by Adam Bergmark 11 Sep '14

11 Sep '14

Wow, I totally forgot about "if impl(ghc>=7.8)". That's the way to go of course! On Thu, Sep 11, 2014 at 12:04 AM, Herbert Valerio Riedel <hvriedel(a)gmail.com > wrote: > On 2014-09-10 at 20:41:27 +0200, Adam Bergmark wrote: > > Hi Mike, something like this should do the trick (untested): > > > > ``` > > flag ghc78 > > description: Using GHC >= 7.8 > > default: True > > > > library > > if flag(ghc78) > > build-depends: > > base >= 4.7 > > bedandbreakfast >= 5 > > else > > build-depends: > > base < 4.7 > > bedandbreakfast >= 4 > > ``` > > > > This uses a non-manual flag so cabal will toggle it if it needs to. > > btw, why not simply use a "if impl(ghc>=7.8)" conditional w/o resorting > to flags? >

1 0

bedandbreakfast needing a release
by Mike Meyer 10 Sep '14

10 Sep '14

I've got a library that needed some simple matrix computation, so I added the bedandbreakfast package. While my library builds fine on both 7.6 and 7.8, the last released version of that package won't build on 7.8. However, the current HUB was update a couple of weeks ago, and now builds on 7.8. Is there some way to capture that information in a cabal file? That if you're using GHC 7.8, you need bedandbreakfast >= 5.*, but for GHC7.6 you can use bedandbreakfast >= 4.*? I did send an email to the maintainer a little over a week ago asking if he could do a release, and haven't gotten either a reply or a release. Any suggestions on what I should do about releasing the updated version of my library?

3 4

ANNOUNCE time-1.5
by Ashley Yakeley 10 Sep '14

10 Sep '14

time-1.5 is now available from Hackage. <http://hackage.haskell.org/package/time> The source for time has now moved to GitHub: <https://github.com/haskell/time>. Send bug reports to the associated issue tracker. * Fixed a bug where tzset was not getting called on Windows. The other changes relate to Data.Time.Format: * time no longer depends on old-locale. The TimeLocale from old-locale has been replaced by a new one defined in Data.Time.Format. * The "intervals" field from TimeLocale has been removed, as it's not used. * The way time-zone abbreviations are parsed has changed. The parsing functions parse single-letter military abbreviations, and also time-zones found in the new "knownTimeZones" field of TimeLocale. Note that (knownTimeZones defaultTimeLocale) contains only the ten zone abbreviations mentioned in RFC822 sec. 5. This is the only standardised list of time-zone abbreviations I know of. Since the abbreviations are a many-to-many mapping, this should encourage people to think carefully about what abbreviations they expect. * New parsing functions parseTimeM, parseTimeOrError, readSTime, readPTime replace now-deprecated parseTime, readTime, readsTime. The new functions have a flag to control parsing of leading and trailing whitespace. -- Ashley Yakeley

3 2

Proposal: Use uninterruptibleMask for cleanup actions in Control.Exception
by Eyal Lotem 06 Sep '14

06 Sep '14

I'd like to propose a change in the behavior of Control.Exception to help guarantee cleanups are not accidentally lost. For example, bracket is defined as: bracket before after thing = mask $ \restore -> do a <- before r <- restore (thing a) `onException` after a _ <- after a return r This definition has a serious problem: "after a" (in either the exception handling case, or the ordinary case) can include interruptible actions which abort the cleanup. This means bracket does not in fact guarantee the cleanup occurs. For example: readMVar = bracket takeMVar putMVar -- If async exception occurs during putMVar, MVar is broken! withFile .. = bracket (openFile ..) hClose -- Async exception during hClose leaks the file handle! Interruptible actions during "before" are fine (as long as "before" handles them properly). Interruptible actions during "after" are virtually always a bug -- at best leaking a resource, and at worst breaking the program's invariants. I propose changing all the cleanup handlers to run under uninterruptibleMask, specifically: *bracket, bracketOnError, bracket_, catch, catchJust, finally, handle, handleJust, onException* should all simply wrap their exception/cancellation handler with uninterruptibleMask. The danger of a deadlock is minimal when compared with the virtually guaranteed buggy incorrect handling of async exceptions during cleanup. -- Eyal

10 14

Re: Formal proposal: replace Data.List.inits
by David Feuer 06 Sep '14

06 Sep '14

Minor errors in copying/memory: initsHO = map ($[]) . scanl q id where q f x = f . (x :) On Sun, Jul 20, 2014 at 2:03 AM, David Feuer <david.feuer(a)gmail.com> wrote: > As previously discussed, Data.List.inits has terrible performance: > something as simple as > > print $ length $ inits [100000] > > will take an absurdly long time. The simplest decent improvement seems to be > > initsHO = map ($[]) . scanl q [] > where > q f x = f . (q :) > > A slight transformation of this by Andrew Seniuk (rasfar on #haskell) > gives the slightly faster > > initsR = map reverse . scanl (flip (:)) [] > > As Henning Thielemann and Edward Kmett pointed out, these perform > poorly when calculating things like `map head $ drop 100000 $ inits > [100050]` because the costs of the reverses or compositions are > monolithic and unshared. Edward Kmett pointed out that this could > probably be fixed by using a queue (although he isn't sure it's worth > doing so). As it turns out, it can, and with only a trivial penalty in > other cases. The following uses a stripped-down partial implementation > of Okasaki's banker's queue (see the attached file for a version with > explanatory comments as well as the benchmark code): > > import Data.Bits (popCount) > import Data.Word (Word) > > data Queue a = Queue {-# UNPACK #-} !Word [a] [a] > > queue :: Word -> [a] -> [a] -> Queue a > queue lp1 f r > | popCount lp1 /= 1 = Queue lp1 f r > | otherwise = Queue lp1 (f ++ reverse r) [] > > emptyQ :: Queue a > emptyQ = Queue 1 [] [] > > snocQ :: Queue a -> a -> Queue a > snocQ (Queue lp1 f r) x = queue (lp1 + 1) f (x:r) > > toListQ :: Queue a -> [a] > toListQ (Queue _ f r) = f ++ reverse r > > initsQ :: [a] -> [[a]] > initsQ = map toListQ . scanl snocQ emptyQ > > > This implementation appears to take care of the performance wrinkle in > initsR and initsHO, while being only very slightly slower in other > contexts. It's longer, certainly, but it's not long. > > I have attached the Criterion report produced by the attached program > comparing initsR to initsQ. Previous tests definitively showed that > initsHO is a small constant factor worse than initsR, and > Data.List.inits is incomparably worse, so I limited this round to > initsR and initsQ. > > I therefore propose that we should replace the current implementation > of inits with initsQ, the queue-based one, unless someone comes up > with something faster and/or simpler very soon.

4 10

Proposal: Add strictly filtering filterM' to Control.Monad
by David Feuer 04 Sep '14

04 Sep '14

We have filterM, that looks like this (although I'm trying to get it changed to use foldr): filterM :: (Monad m) => (a -> m Bool) -> [a] -> m [a] filterM _ [] = return [] filterM p (x:xs) = do flg <- p x ys <- filterM p xs return (if flg then x:ys else ys) This can cause a problem in some cases when used with IO, strict ST, or similar. In particular, it doesn't actually discard any elements of the list until all the predicate computations have run. Rather, it accumulates a chain of closures containing elements of the input and (possibly unevaluated) results of the (p x) computations. If the result of (p x) is usually False, so the input list is much longer than the output list, this can lead a program to run out of memory unnecessarily. This behavior cannot be avoided without changing semantics in some cases, as Dan Doel pointed out to me. In particular, a computation (p x) may run successfully to completion but produce a bottom value. PROPOSAL Add a function like this: filterM' :: (Monad m) => (a -> m Bool) -> [a] -> m [a] filterM' p = go [] where go _ [] = return [] go acc (x:xs) = do flq <- p x ys <- if flq then go (x:acc) xs else go acc xs return (reverse acc) This can be twisted somewhat harder into a right fold if we want: filterM' :: (Monad m) => (a -> m Bool) -> [a] -> m [a] filterM' p xs = foldr go return xs [] where go x r = \acc -> do flq <- p x ys <- if flq then r (x:acc) else r acc return (reverse acc) The advantage of this function is that instead of building a chain of closures proportional to the size of its *input* (but likely larger), it builds a list equal in size to its (possibly much smaller) *output*.

2 2

PROPOSAL: Make Data.Type.Bool.If polykinded
by Merijn Verstraaten 03 Sep '14

03 Sep '14

Ola! Currently we have: type family If cond tru fls where If True tru fls = tru If False tru fls = fls Unfortunately, this appears to turned into a monomorphicly kinded type family by GHC, which means it’s impossible to do foo :: If cond () (“Condition does not hold” ~ “”) => Foo -> Bar or similar fancy constraints. I hereby propose altering If to: type family If (cond :: Bool) (tru :: k) (fls :: k) :: k where If True tru fls = tru If False tru fls = fls Allowing it to work with kinds other than *. Discussion period: 2 weeks? Seems like a minor change. Cheers, Merijn

3 3