- Libraries - Haskell.org

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

DEPRECATED pragma for exports
by Ben Gamari 27 Aug '15

27 Aug '15

Hello everyone, I was looking through the list of bugs milestoned for 7.12 today and stumbled across #4879. This ticket has been with us since 7.0.1 and proposes support for the DEPRECATE pragma on exports. I seem to remember seeing this feature being requested numerous times to help in dealing with transitional issues in the core libraries. If this is the case then we should aim to get this feature in to 7.12. This shouldn't be a difficult task as there is a working patch [1] in need of only a bit of minor refactoring already attached to the ticket. What we need to make this happen is for someone to step up and write a specification (on the GHC Wiki) defining the syntax and its semantics, and then check that the patch faithfully implements that specification. Would any of you be willing to do this? Cheers, - Ben [1] https://phabricator.haskell.org/D638

1 0

IsString [Char] instance
by Dan Doel 12 Aug '15

12 Aug '15

Greetings, Today, someone came into #haskell and asked why they couldn't type the equivalent of: > "hi" ++ "bye" into GHCi with OverloadedStrings enabled. The answer is that it's ambiguous, because (++) only determines the strings to be [a], and not [Char]. I noticed that this could actually be solved by making the instance: instance (a ~ Char) => IsString [a] where ... Which causes [Char] to be inferred as soon as [a] is. I then searched my libraries mail and noticed that we'd discussed this two years ago. The proposal for this instance change was rejected based on ExtendedDefaultRules being beefed up to solve this case. But then no one actually implemented the better defaulting. So, I'm proposing that the issue be fixed for real. I'm not terribly concerned with how it gets fixed, but there's not a great reason for this to not behave better than it currently does. If someone steps up and makes defaulting better, than that's great. But if not, then the libraries committee can fix this very easily for GHC 7.12, and I think it's better to do so than to wait if there are no signs that the alternative is going to happen. I don't think we need to nail down which of the two solutions we're going to choose right now, but it'd be good to resolve that we're going to fix it, one way or another, by some well defined date. Here's a link to the previous discussion: http://comments.gmane.org/gmane.comp.lang.haskell.libraries/20088 Discussion period: 2 weeks -- Dan

8 12

Proposal: newtype for applicatives of monoids
by David Feuer 12 Aug '15

12 Aug '15

Sorry for the terrible title, but I think we should add something like the following to Data.Monoid (I already mentioned this in the discussion of a Monoid instance for ZipList). newtype Appl f m = Appl (f m) instance (Applicative f, Monoid m) => Monoid (Appl f m) where mempty = Appl $ pure mempty mplus (Appl x) (Appl y) = Appl $ liftA2 mplus x y It may be possible to use coercions to improve mplus; I haven't tried it. This type is the same as WrappedApplicative from semigroupoids, do it might be best just to give it that name.

10 13

Re: [core libraries] Re: mapM /= traverse?
by Edward Kmett 03 Aug '15

03 Aug '15

At the very least, it does seem like we're going to need to do a broader survey of the instances out there, as well as fix a lot more Applicative instances to have a better (*>) first as well as thoroughly document what to do, if we want to proceed on this front. If we ultimately want to remove mapM from the class to get it a more permissive type signature, and get mapM_ from Foldable to have the more general signature to boot, then we'll need to figure out how to address these concerns. It still strikes me as the right general direction to go in, but this is troubling. -Edward On Mon, Aug 3, 2015 at 12:33 PM, Ben Gamari <ben(a)well-typed.com> wrote: > Edward Kmett <ekmett(a)gmail.com> writes: > > > On Tue, May 12, 2015 at 3:58 AM, Simon Marlow <marlowsd(a)gmail.com> > wrote: > > > >> > >> Yes, I'm not really concerned that mapM is a method of Traversable > rather > >> than just being an alias for traverse, but I'm wondering why we define > it > >> in the list instance rather than using the default. > >> > > > > We were pretty paranoid about introducing space or time regressions and > > didn't have a proof that we wouldn't introduce them by changing something > > there, so we left it alone. > > > On a related note, D924 [1] proposed that mapM_ be redefined in > terms of traverse_. Unfortunately at least one monad in GHC itself was > adversely affected [2] by this change, resulting in non-linear complexity > in > a previously well-behaved function (a minimal demonstration of this can > be found below). > > We discussed this in the GHC weekly meeting and felt that we should > ensure that the libraries group was aware of this issue. > > Cheers, > > - Ben > > > [1] https://phabricator.haskell.org/D924 > [2] https://ghc.haskell.org/trac/ghc/ticket/10711 > [3] Demonstration of regression in complexity of mapM_ when expressed in > terms of `traverse_`, > > {{{ > module Main where > > import Control.Monad hiding (mapM_) > import Prelude hiding (mapM_) > > -- | Testcase derived from Assembler monad in ByteCodeAsm > data Assembler a > = Thing Int (Int -> Assembler a) > | Pure a > > instance Functor Assembler where > fmap = liftM > > instance Applicative Assembler where > pure = return > (<*>) = ap > > instance Monad Assembler where > return = Pure > Pure x >>= f = f x > Thing i k >>= f = Thing i (k >=> f) > > -- This is traverse_ > mapA_ :: (Foldable t, Monad f) => (a -> f b) -> t a -> f () > mapA_ f = foldr ((*>) . f) (pure ()) > > -- This is the current definition > mapM_ :: (Foldable t, Monad f) => (a -> f b) -> t a -> f () > mapM_ f = foldr ((>>) . f) (pure ()) > > test = map (\i->Thing i (const $ return 2)) [0..10000] > > doTestM = mapM_ id test > doTestA = mapA_ id test > > run :: Assembler a -> a > run (Thing i f) = run (f i) > run (Pure r) = r > {-# NOINLINE run #-} > > main :: IO () > main = print $ run doTestM > }}} > > -- > You received this message because you are subscribed to the Google Groups > "haskell-core-libraries" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to haskell-core-libraries+unsubscribe(a)googlegroups.com. > For more options, visit https://groups.google.com/d/optout. >

2 1