- Libraries - Haskell.org

Proposal: Derive Lift for all data types in the template-haskell library
by Ryan Scott 26 Sep '15

26 Sep '15

The DeriveLift extension has landed in GHC HEAD, so now it's become apparent that the bikeshed needs a new coat of paint. The only Lift instances at the moment are base types [1], but with DeriveLift, it would be possible to implement Lift for many for data types with ease. I'll make (what I hope is) an uncontroversial first suggestion: we should derive Lift for every data type in the template-haskell library itself. These instances have proved to be useful for library authors who need to convert to and from the TH AST (th-desugar, for example, relies on this functionality via orphan instances [2]). Adding this would break some code out in the wild (the th-lift [3] and th-orphans [4] packages come to mind; there may be others), so I'll request feedback before marching forth with this proposal. Ryan S. ----- [1] http://hackage.haskell.org/package/template-haskell-2.10.0.0/docs/Language-… [2] http://hackage.haskell.org/package/th-desugar-1.5.4.1/docs/src/Language-Has… [3] http://hackage.haskell.org/package/th-lift [4] http://hackage.haskell.org/package/th-orphans

3 4

ANN: CfN for new Haskell Prime language committee
by Herbert Valerio Riedel 23 Sep '15

23 Sep '15

Dear Haskell Community, In short, it's time to assemble a new Haskell Prime language committee. Please refer to the CfN at https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html for more details. Cheers, hvr -- PGP fingerprint: 427C B69A AC9D 00F2 A43C AF1C BA3C BA3F FE22 B574

1 0

Proposal: Data.Functor.<.> for `fmap f2 . f1`
by Ömer Sinan Ağacan 21 Sep '15

21 Sep '15

I don't know if "I find this very useful" is enough for adding a function to base, but here it goes: infixl 4 <.> (<.>) :: Functor f => (b -> c) -> (a -> f b) -> (a -> f c) f1 <.> f2 = fmap f1 . f2 {-# INLINE (<.>) #-} I first defined this couple of months ago and I find myself looking for this function all the time now. One problem with this is that the name is used by widely used `filepath` library.

8 8

Proposal: Export Any from Unsafe.Coerce
by David Feuer 15 Sep '15

15 Sep '15

Any is the sanctioned intermediary for unsafeCoerce. GHC claims to guarantee that any lifted type can be coerced to and from Any without harm. Yet Any seems to be available only from the deeply mystical GHC.Prim, which users outside the GHC source tree are never supposed to import. While GHC.Exts would be an acceptable place, I think Unsafe.Coerce is more appropriate, and will make it easier for users to find this type.

4 3

List function pragma discipline
by Joachim Breitner 11 Sep '15

11 Sep '15

Dear list, I was working on https://ghc.haskell.org/trac/ghc/ticket/10788 (performance regressions involving minimum), and I found it quite unsatisfactory to twiddle with individual functions, based on individual test cases, this way. Of course I can improve things for a combination of functions and testcase, but if so, shouldn’t I be improving others as well? What about other test cases – will they regress? How should I balance the goals of speed, code size and simplicity? This feels more like a random walk rather than hill-climbing, let alone a disciplined approach to the problem. Can we have a disciplined approach? I.e. a set of guidelines that work well in general, can be documented and communicated to the user, and that we can follow in such cases? Here is a rough draft, more to show what I am aiming for, rather than a finished work: * Functions that can take part in list fusion have RULES to rewrite them in terms of foldr/build, but also RULES to write them back. Phase control ensures that this is done by phase 0, and the following applies to phase 0. * Recursive non-polymorphic non-higher-order functions are not marked as INLINE (and thus not inlineable, beside possibly the wrapper of a worker-wrapper split). * Recursive polymorphic non-higher-order functions are marked as INLINEABLE, and SPECIALIZE pragmas are given for common cases. (Example: minimum, maximum). * Recursive higher-order functions are implemented with a local recursive function, to allow for inlining (foldl, foldr, maximumBy), at least if there is a chance of further optimizations due to strictness analysis. Given such a guideline, I would then know what to do with such a ticket, instead of stabbing in the dark. It might mean that we would have to tell a user who observes suboptimal performance in one case that this is unavoidable (we cannot optimize for everyone) and possibly explain how to work around the issue. Or we might find that the discipline could be improved, but then the improvement should be applied to all functions. Thoughts? Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

4 3

ANNOUNCE: graphviz-2999.18.0.0
by Ivan Lazar Miljenovic 06 Sep '15

06 Sep '15

This is my "sorry it took so long" release: I'd like to apologise to all the people that have been nagging^W gently asking me when a GHC 7.10.*-compatible release would be available that it's taken me until now to do this, but I'm finally pleased to be able to say that you can now use my graphviz library to generate/parse Dot code and visualise graphs using the Graphviz suite of tools. As part of this version release, graphviz is now developed using git and can be found on GitHub: https://github.com/ivan-m/graphviz The major version bump is due to an extra attribute being made available, so in most (all?) cases you can safely version bump your existing dependencies. -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com http://IvanMiljenovic.wordpress.com

1 0

Proposal: generalise Monoid's mconcat
by Fermin Reig 01 Sep '15

01 Sep '15

We could generalise: mconcat:: [a] -> a mconcat = foldr mappend memtpy to: mconcat:: Foldable t => t a -> a mconcat = foldr mappend memtpy -- even -- mconcat = fold Fermin PS: I cannot find a proposal for this in the archives, apologies if it's been raised before and I missed it.

9 11

Documentation for GHC.IO.Exception
by Phil Ruffwind 29 Aug '15

29 Aug '15

On Hackage, there seems to be no documentation for GHC.IO.Exception in base, but the package can in fact be imported so it's not exactly an internal package. directory and likely many other packages do use the GHC-specific error types like InappropriateType in exceptions, so it would be useful if there were a documentation page for these things even if there isn't any text. As it is right now, the discoverability of these error types is very low as you need to know the magical URL to show the source code: https://hackage.haskell.org/package/base/docs/src/GHC.IO.Exception.html That's also partly a problem with Haddock; AFAIK there's no way to navigate to the Source Code packages of modules whose documentation is disabled, even though they are in fact present if you can figure out the URL. So would it be OK to open up this module or is there a reason for keeping them discreet?

1 0

Problem running zlib test suite: ghc: unrecognised flag: -fno-stack-protector
by Andrés Sicard-Ramírez 29 Aug '15

29 Aug '15

Hi, I'm trying of running the zlib test suite using GHC 7.10.2 and hsc2hs 0.67: $ darcs get http://code.haskell.org/zlib/ $ cd zlib $ cabal install $ cd test $ make test hsc2hs --cc=ghc --ld=ghc --lflag=-lz -o ../Codec/Compression/Zlib/Stream.hs ../Codec/Compression/Zlib/Stream.hsc ghc: unrecognised flag: -fno-stack-protector ... compiling ../Codec/Compression/Zlib/Stream_hsc_make.c failed (exit code 1) command was: ghc -c ../Codec/Compression/Zlib/Stream_hsc_make.c -o ../Codec/Compression/Zlib/Stream_hsc_make.o -fno-stack-protector -I/usr/local/stow/ghc-7.10.2/lib/ghc-7.10.2/include/ Am I doing something wrong? Best, -- Andrés

1 0

Cabal and simultaneous installations of the same package
by Simon Peyton Jones 29 Aug '15

29 Aug '15

Dear Cabal developers You'll probably have seen the thread about the Haskell Platform. Among other things, this point arose: | Another thing we should fix is the (now false) impression that HP gets in | the way of installing other packages and versions due to cabal hell. People mean different things by "cabal hell", but the inability to simultaneously install multiple versions of the same package, compiled against different dependencies is certainly one of them, and I think it is the one that Yitzchak is referring to here. But some time now GHC has allowed multiple versions of the same package (compiled against different dependencies) to be installed simultaneously. So all we need to do is to fix Cabal to allow it too, and thereby kill of a huge class of cabal-hell problems at one blow. But time has passed and it hasn't happened. Is this because I'm misunderstanding? Or because it is harder than I think? Or because there are much bigger problems? Or because there is insufficient effort available? Or what? Unless I'm way off beam, this "multiple installations of the same package" thing has been a huge pain forever, and the solution is within our grasp. What's stopping us grasping it? Simon

7 16