- Glasgow-haskell-users

Feedback on -Wredundant-constraints
by Adam Foltzer 12 Jun '16

12 Jun '16

With 8.0.1 freshly arrived, I'm taking on the task of updating a number of our larger projects here at Galois. I made a couple of these comments briefly on a relevant Trac ticket[1], but I wanted to open this discussion to a wider audience. We tend to use -Wall (and -Werror, in CI environments), and so I've had to make decisions about how to handle the new -Wredundant-constraints warnings. So far, I've come to think of it as two different warnings that happen to be combined: Warning 1: a warning for constraints made redundant by superclass relationships, and Warning 2: a warning for unused constraints Overall I'm a fan of Warning 1. It seems very much in the spirit of other warnings such as unused imports. The only stumbling block is how it affects the 3-release compatibility plan with respect to, e.g., the AMP. Most of our code targets a 2-release window, though, so in every such case it has been fine for us to simply remove the offending constraint. Warning 2 on the other hand is far more dubious to me. In the best case, it finds constraints that through oversight or non-local changes are truly no longer necessary in the codebase. This is nice, but the much more common case in our code is that we've made a deliberate decision to include that constraint as part of our API design. The most painful example of this I've hit so far is in an API of related functions, where we've put the same constraint on each function even when the implementation of that particular function might not need that constraint. This is good for consistency and forward-looking compatibility (what if we need that constraint in the next version?). The warning's advice in this case makes the API harder to understand, and less abstract (the client shouldn't care or know that f needs Functor, but g doesn't, if both will always be used in a Functor context). On another level, Warning 2 is a warning that we could have given a more general type to a definition. We quite rightly don't do this for the non-constraint parts of the type signatures, so why are we doing it for the constraints? I'm happy that Warning 1 is now around, but Warning 2 feels much more like an opinionated lint check, and I really wish it wasn't part of -Wall. [1]: https://ghc.haskell.org/trac/ghc/ticket/10635#comment:15

5 9

Call for talks: Haskell Implementors Workshop 2016, Sep 24 (FIXED), Nara
by Edward Z. Yang 09 Jun '16

09 Jun '16

(...and now with the right date in the subject line!) Call for Contributions ACM SIGPLAN Haskell Implementors' Workshop http://haskell.org/haskellwiki/HaskellImplementorsWorkshop/2016 Nara, Japan, 24 September, 2016 Co-located with ICFP 2016 http://www.icfpconference.org/icfp2016/ Important dates --------------- Proposal Deadline: Monday, 8 August, 2016 Notification: Monday, 22 August, 2016 Workshop: Saturday, 24 September, 2016 The 8th Haskell Implementors' Workshop is to be held alongside ICFP 2016 this year in Nara. It is a forum for people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure, to share their work and discuss future directions and collaborations with others. Talks and/or demos are proposed by submitting an abstract, and selected by a small program committee. There will be no published proceedings; the workshop will be informal and interactive, with a flexible timetable and plenty of room for ad-hoc discussion, demos, and impromptu short talks. Scope and target audience ------------------------- It is important to distinguish the Haskell Implementors' Workshop from the Haskell Symposium which is also co-located with ICFP 2016. The Haskell Symposium is for the publication of Haskell-related research. In contrast, the Haskell Implementors' Workshop will have no proceedings -- although we will aim to make talk videos, slides and presented data available with the consent of the speakers. In the Haskell Implementors' Workshop, we hope to study the underlying technology. We want to bring together anyone interested in the nitty-gritty details behind turning plain-text source code into a deployed product. Having said that, members of the wider Haskell community are more than welcome to attend the workshop -- we need your feedback to keep the Haskell ecosystem thriving. The scope covers any of the following topics. There may be some topics that people feel we've missed, so by all means submit a proposal even if it doesn't fit exactly into one of these buckets: * Compilation techniques * Language features and extensions * Type system implementation * Concurrency and parallelism: language design and implementation * Performance, optimisation and benchmarking * Virtual machines and run-time systems * Libraries and tools for development or deployment Talks ----- At this stage we would like to invite proposals from potential speakers for talks and demonstrations. We are aiming for 20 minute talks with 10 minutes for questions and changeovers. We want to hear from people writing compilers, tools, or libraries, people with cool ideas for directions in which we should take the platform, proposals for new features to be implemented, and half-baked crazy ideas. Please submit a talk title and abstract of no more than 300 words. Submissions should be made via HotCRP. The website is: https://icfp-hiw16.hotcrp.com/ We will also have a lightning talks session which will be organised on the day. These talks will be 5-10 minutes, depending on available time. Suggested topics for lightning talks are to present a single idea, a work-in-progress project, a problem to intrigue and perplex Haskell implementors, or simply to ask for feedback and collaborators. Organisers ---------- * Joachim Breitner (Karlsruhe Institut für Technologie) * Duncan Coutts (Well Typed) * Michael Snoyman (FP Complete) * Luite Stegeman (ghcjs) * Niki Vazou (UCSD) * Stephanie Weirich (University of Pennsylvania) * Edward Z. Yang - chair (Stanford University)

1 0

Call for talks: Haskell Implementors Workshop 2016, Aug 24, Nara
by Edward Z. Yang 09 Jun '16

09 Jun '16

Call for Contributions ACM SIGPLAN Haskell Implementors' Workshop http://haskell.org/haskellwiki/HaskellImplementorsWorkshop/2016 Nara, Japan, 24 September, 2016 Co-located with ICFP 2016 http://www.icfpconference.org/icfp2016/ Important dates --------------- Proposal Deadline: Monday, 8 August, 2016 Notification: Monday, 22 August, 2016 Workshop: Saturday, 24 September, 2016 The 8th Haskell Implementors' Workshop is to be held alongside ICFP 2016 this year in Nara. It is a forum for people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure, to share their work and discuss future directions and collaborations with others. Talks and/or demos are proposed by submitting an abstract, and selected by a small program committee. There will be no published proceedings; the workshop will be informal and interactive, with a flexible timetable and plenty of room for ad-hoc discussion, demos, and impromptu short talks. Scope and target audience ------------------------- It is important to distinguish the Haskell Implementors' Workshop from the Haskell Symposium which is also co-located with ICFP 2016. The Haskell Symposium is for the publication of Haskell-related research. In contrast, the Haskell Implementors' Workshop will have no proceedings -- although we will aim to make talk videos, slides and presented data available with the consent of the speakers. In the Haskell Implementors' Workshop, we hope to study the underlying technology. We want to bring together anyone interested in the nitty-gritty details behind turning plain-text source code into a deployed product. Having said that, members of the wider Haskell community are more than welcome to attend the workshop -- we need your feedback to keep the Haskell ecosystem thriving. The scope covers any of the following topics. There may be some topics that people feel we've missed, so by all means submit a proposal even if it doesn't fit exactly into one of these buckets: * Compilation techniques * Language features and extensions * Type system implementation * Concurrency and parallelism: language design and implementation * Performance, optimisation and benchmarking * Virtual machines and run-time systems * Libraries and tools for development or deployment Talks ----- At this stage we would like to invite proposals from potential speakers for talks and demonstrations. We are aiming for 20 minute talks with 10 minutes for questions and changeovers. We want to hear from people writing compilers, tools, or libraries, people with cool ideas for directions in which we should take the platform, proposals for new features to be implemented, and half-baked crazy ideas. Please submit a talk title and abstract of no more than 300 words. Submissions should be made via HotCRP. The website is: https://icfp-hiw16.hotcrp.com/ We will also have a lightning talks session which will be organised on the day. These talks will be 5-10 minutes, depending on available time. Suggested topics for lightning talks are to present a single idea, a work-in-progress project, a problem to intrigue and perplex Haskell implementors, or simply to ask for feedback and collaborators. Organisers ---------- * Joachim Breitner (Karlsruhe Institut für Technologie) * Duncan Coutts (Well Typed) * Michael Snoyman (FP Complete) * Luite Stegeman (ghcjs) * Niki Vazou (UCSD) * Stephanie Weirich (University of Pennsylvania) * Edward Z. Yang - chair (Stanford University)

1 0

Re: TDNR without new operators or syntax changes
by Jeremy . 29 May '16

29 May '16

Yes, that it indeed was I meant. AntC seems to be replying to a much more complicated/invasive proposal than what I had intended, apologies if I wasn't clear. (I see in retrospect that I may have misunderstood the original TDNR proposal, understandably leading to confusion.) 1. If the compiler encounters a term f a, and there is more than one definition for f in scope (after following all of the usual rules for qualified imports); 2. And exactly one of these definitions matches the type of a (or the expected type of f if given); 3. Then this is the definition to use. That is all, although point 2 could be extended to consider the return type of f or other arguments as well. Even with the extension on, it would have no effect on programs which compile without it. This has nothing to do with ORF, which relies on magic type classes (although there is some overlap in what it can achieve). The primary use-case I had in mind is disambiguating name clashes between local and/or unqualified imports. Cross-posting to cafe and libraries as this doesn't seem to have attracted a lot of interest in users. Maybe it's just a boring proposal, maybe I didn't post it to the right list.

9 15

[ANNOUNCE] GHC 8.0.1 is available!
by Ben Gamari 27 May '16

27 May '16

=============================================== The Glasgow Haskell Compiler -- version 8.0.1 =============================================== The GHC developers are very pleased to announce the release of the first new super-major version of our Haskell compiler in six years, GHC 8.0.1. This release features dozens of exciting developments including, * A more refined interface for implicit call-stacks, allowing libraries to provide more helpful runtime error messages to users * The introduction of the DuplicateRecordFields language extension, allowing multiple record types to declare fields of the same name * Significant improvements in error message readability and content, including facilities for libraries to provide custom error messages, more aggressive warnings for fragile rewrite rules, and more helpful errors for missing imports * A rewritten and substantially more thorough pattern match checker, providing more precise exhaustiveness checking in GADT pattern matches * More reliable debugging information including experimental backtrace support, allowing better integration with traditional debugging tools * Support for desugaring do-notation to use Applicative combinators, allowing the intuitive do notation to be used in settings which previously required the direct use of Applicative combinators * The introduction of Strict and StrictData language extensions, allowing modules to be compiled with strict-by-default evaluation of bindings * Great improvements in portability, including more reliable linking on Windows, a new PPC64 code generator, support for the AIX operating system, unregisterised m68k support, and significant stabilization on ARM targets * A greatly improved user's guide, with beautiful and modern PDF and HTML output * Introduction of type application syntax, reducing the need for proxies * More complete support for pattern synonyms, including record pattern synonyms and the ability to export patterns "bundled" with a type, as you would a data constructor * Support for injective type families and recursive superclass relationships * An improved generics representation leveraging GHC's support for type-level literals * The TypeInType extension, which unifies types and kinds, allowing GHC to reason about kind equality and enabling promotion of more constructs to the type level * ...and more! A more thorough list of the changes included in this release can be found in the release notes, https://downloads.haskell.org/~ghc/8.0.1/docs/html/users_guide/8.0.1-notes.… As always, we have collected various points of interest for users of previous GHC releases on the GHC 8.0 migration page, https://ghc.haskell.org/trac/ghc/wiki/Migration/8.0 Please let us know if you encounter anything missing or unclear on this page. This release is the culmination of nearly eighteen months of effort by over one hundred contributors. We'd like to thank everyone who has contributed code, bug reports, and feedback over the past year. It's only because of their efforts that GHC continues to evolve. How to get it ~~~~~~~~~~~~~ Both the source tarball and binary distributions for a wide variety of platforms are available at, http://www.haskell.org/ghc/ Background ~~~~~~~~~~ Haskell is a standardized lazy functional programming language. The Glasgow Haskell Compiler (GHC) is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating efficient code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces. GHC is distributed under a BSD-style open source license. Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, can be found on the GHC wiki http://ghc.haskell.org/trac/ghc/wiki/Platforms Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://ghc.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on getting started with hacking on GHC are available from GHC's developer site, http://ghc.haskell.org/trac/ghc/ Community Resources ~~~~~~~~~~~~~~~~~~~ There are mailing lists for GHC users, develpoers, and monitoring bug tracker activity; to subscribe, use the web interfaces at http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets There are several other Haskell and GHC-related mailing lists on www.haskell.org; for the full list, see https://mail.haskell.org/cgi-bin/mailman/listinfo Some GHC developers hang out on the #ghc and #haskell of the Freenode IRC network, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug

2 1

Pattern synonyms and GADTs in GHC 8.0.1
by Emil Axelsson 26 May '16

26 May '16

I have a problem where a pattern synonym doesn't provide the expected type refinement in GHC 8.0.1. > {-# LANGUAGE GADTs #-} > {-# LANGUAGE PatternSynonyms #-} > > data Exp a > where > Num :: (Eq a, Num a) => a -> Exp a > Add :: (Eq a, Num a) => Exp a -> Exp a -> Exp a > > pattern NumP a = Num a > > pattern AddP :: (Num a, Eq a) => Exp a -> Exp a -> Exp a > pattern AddP a b = Add a b > > simplifyP :: Exp a -> Exp a > simplifyP (AddP a (NumP 0)) = a > simplifyP a = a This gives the error • No instance for (Eq a) arising from a pattern Possible fix: add (Eq a) to the context of the type signature for: simplifyP :: Exp a -> Exp a • In the pattern: AddP a (NumP 0) In an equation for ‘simplifyP’: simplifyP (AddP a (NumP 0)) = a If I remove the type signature for `AddP`, the code goes through. Unfortunately, in my real code I need the type signature in order to resolve overloading. GHC 7.10 didn't have this problem. Is this a bug? / Emil

2 3

Cannot install 8.0.1 from bindist
by Peter 25 May '16

25 May '16

Trying to install ghc-8.0.1-x86_64-centos67-linux.tar.xz with: ./configure --prefix={prefix} make install-strip gives me an error. The tail of the log is: Registering ghc-8.0.1... for f in '{prefix}/lib/ghc-8.0.1/package.conf.d'/*; do create () { touch "$1" && chmod 644 "$1" ; } && create "$f"; done /usr/bin/install -c -m 755 -d "{prefix}/bin" for i in utils/hp2ps/dist/build/tmp/hp2ps; do \ /usr/bin/install -c -m 755 -s $i "{prefix}/bin" ; \ done /usr/bin/install -c -m 755 -d "{prefix}/lib/ghc-8.0.1/bin" for i in inplace/lib/bin/ghc-split; do \ /usr/bin/install -c -m 755 $i "{prefix}/lib/ghc-8.0.1/bin"; \ done /usr/bin/install -c -m 755 -d "{prefix}/share/doc/ghc-8.0.1" /usr/bin/install -c -m 755 -d "{prefix}/share/doc/ghc-8.0.1/html" /usr/bin/install -c -m 644 docs/index.html "{prefix}/share/doc/ghc-8.0.1/html" /usr/bin/install -c -m 755 -d "{prefix}/share/doc/ghc-8.0.1/html/libraries" for i in libraries/dist-haddock/*; do \ /usr/bin/install -c -m 644 $i "{prefix}/share/doc/ghc-8.0.1/html/libraries/"; \ done /usr/bin/install -c -m 644 libraries/prologue.txt "{prefix}/share/doc/ghc-8.0.1/html/libraries/" /usr/bin/install -c -m 755 libraries/gen_contents_index "{prefix}/share/doc/ghc-8.0.1/html/libraries/" mkdir: cannot create directory `doc/aries/ghc-prim-0.5.0.0': No such file or directory Is there any way of knowing what the call to mkdir is relative to, and why it's trying to create the directory there? -- View this message in context: http://haskell.1045720.n5.nabble.com/Cannot-install-8-0-1-from-bindist-tp58… Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

2 2

suboptimal ghc code generation in IO vs equivalent pure code case
by Harendra Kumar 16 May '16

16 May '16

I have a loop which runs millions of times. For some reason I have to run it in the IO monad. I noticed that when I convert the code from pure to IO monad the generated assembly code in essence is almost identical except one difference where it puts a piece of code in a separate block which is making a huge difference in performance (4-6x slower). I want to understand what makes GHC to generate code in this way and if there is anything that can be done at source level (or ghc option) to control that. The pure code looks like this: decomposeChars :: [Char] -> [Char] decomposeChars [] = [] decomposeChars [x] = case NFD.isDecomposable x of True -> decomposeChars (NFD.decomposeChar x) False -> [x] decomposeChars (x : xs) = decomposeChars [x] ++ decomposeChars xs The equivalent IO code is this: decomposeStrIO :: [Char] -> IO [Char] decomposeStrPtr !p = decomposeStrIO where decomposeStrIO [] = return [] decomposeStrIO [x] = do res <- NFD.isDecomposable p x case res of True -> decomposeStrIO (NFD.decomposeChar x) False -> return [x] decomposeStrIO (x : xs) = do s1 <- decomposeStrIO [x] s2 <- decomposeStrIO xs return (s1 ++ s2) The difference is in how the code corresponding to the call to the (++) operation is generated. In the pure case the (++) operation is inline in the main loop: _cn5N: movq $sat_sn2P_info,-48(%r12) movq %rax,-32(%r12) movq %rcx,-24(%r12) movq $:_con_info,-16(%r12) movq 16(%rbp),%rax movq %rax,-8(%r12) movq $GHC.Types.[]_closure+1,(%r12) leaq -48(%r12),%rsi leaq -14(%r12),%r14 addq $40,%rbp jmp GHC.Base.++_info In the IO monad version this code is placed in a separate block and a call is placed in the main loop: the main loop call site: _cn6A: movq $sat_sn3w_info,-24(%r12) movq 8(%rbp),%rax movq %rax,-8(%r12) movq %rbx,(%r12) leaq -24(%r12),%rbx addq $40,%rbp jmp *(%rbp) out of the line block - the code that was in the main loop in the previous case is now moved to this block (see label _cn5s below): sat_sn3w_info: _cn5p: leaq -16(%rbp),%rax cmpq %r15,%rax jb _cn5q _cn5r: addq $24,%r12 cmpq 856(%r13),%r12 ja _cn5t _cn5s: movq $stg_upd_frame_info,-16(%rbp) movq %rbx,-8(%rbp) movq 16(%rbx),%rax movq 24(%rbx),%rbx movq $:_con_info,-16(%r12) movq %rax,-8(%r12) movq $GHC.Types.[]_closure+1,(%r12) movq %rbx,%rsi leaq -14(%r12),%r14 addq $-16,%rbp jmp GHC.Base.++_info _cn5t: movq $24,904(%r13) _cn5q: jmp *-16(%r13) Except this difference the rest of the assembly looks pretty similar in both the cases. The corresponding dump-simpl output for the pure case: False -> ++ @ Char (GHC.Types.: @ Char ww_amuh (GHC.Types.[] @ Char)) (Data.Unicode.Internal.Normalization.decompose_$sdecompose ipv_smuv ipv1_smuD); And for the IO monad version: False -> case $sa1_sn0g ipv_smUT ipv1_smV6 ipv2_imWU of _ [Occ=Dead] { (# ipv4_XmXv, ipv5_XmXx #) -> (# ipv4_XmXv, ++ @ Char (GHC.Types.: @ Char sc_sn0b (GHC.Types.[] @ Char)) ipv5_XmXx #) }; The dump-simpl output is essentially the same except the difference due to the realworld token in the IO case. Why is the generated code different? I will appreciate if someone can throw some light on the reason or can point to the relevant ghc source to look at where this happens. I am using ghc-7.10.3 in native code generation mode (no llvm). Thanks, Harendra

5 11

Magic classes for Overloaded Record Fields, overlaps, FunDeps
by AntC 16 May '16

16 May '16

There's an intriguing comment here wrt anonymous records: https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/ MagicClasses#Designextension:anonymousrecords (End of the section) "... this doesn't quite work, because the two instances overlap, but it is possible with a bit more trickery" I could well understand if everybody's forgotten what was the "trickery", because ORF has been so long in the pipeline, but could anyone explain? Reason for the q: I'm looking at anonymous records myself, including extending, shortening and joining anon records. And yes overlapping instances are everywhere. Using type families isn't being too ergonomic. And I notice ORF has used FunDeps. But for me, FunDeps in the HList style is also rather ugly. Is there some trickery I'm missing? Thanks AntC

3 6

Looking for GHC compile-time performance tests
by Ben Gamari 07 May '16

07 May '16

tl;dr. Do you have a Haskell project which GHC now compiles more slowly than in the past? If you would like to see your program's compilation time improve in 8.2, reduce it to a minimal testcase, and provide it to us via Trac. Good news everyone, GHC 8.2 will be a release largely targetting consolidation instead of new features. In particular, we will focus on compiler performance issues. One of the challenges of this task is knowing in which ways GHC has regressed. It is currently hard to know how much of the apparent compiler performance regression is due to GHC getting slower and how much is due to users demanding more of it. To better understand the performance of our compiler, we would like to collect modern Haskell code samples that exhibit compile-time performance issues (either regressions or otherwise). For this we are asking for your help: we are looking for projects that, * are small-to-moderate-sized Haskell programs which you believe have regressed in compile time in the last few GHC releases * have minimal build dependencies, in the ideal case none outside of the standard GHC boot libraries * can be licensed for use under 3-clause BSD In some cases we may also be able to make use of examples with a few library dependencies that are necessary to demonstrate the performance issue (for instance, a suspected issue stemming from stream fusion requiring Conduit). For performance issues exhibiting non-linear scaling in some quantity (e.g. the size of a type in the program), it would be extremely helpful if the testcase exposed a "knob" demonstrating this scaling. So, if you would like to see your program's compilation time improve in GHC 8.2, put some time into reducing it to something minimal, submit it to us via a Trac ticket, and let us know in this thread. Thanks for your help! Cheers, - Ben

7 7