- ghc-devs - Haskell.org

Haskell Implementors' Workshop Call for Talks
by Richard Eisenberg 04 Jul '17

04 Jul '17

Call for Contributions ACM SIGPLAN Haskell Implementors' Workshop http://icfp17.sigplan.org/track/hiw-2017 Oxford, UK, 9 September, 2017 Co-located with ICFP 2017 http://www.icfpconference.org/icfp2017/ Important dates --------------- Proposal Deadline: Thursday, 6 July, 2017 Notification: Thursday, 20 July, 2017 Workshop: Saturday, 9 September, 2017 The 9th Haskell Implementors' Workshop is to be held alongside ICFP 2017 this year in Oxford. 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 open spaces in the timetable and 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 2017. 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. The Implementors' Workshop is an ideal place to describe a Haskell extension, describe works-in-progress, demo a new Haskell-related tool, or even propose future lines of Haskell development. Members of the wider Haskell community encouraged to attend the workshop -- we need your feedback to keep the Haskell ecosystem thriving. Students working with Haskell are specially encouraged to share their work. 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 ----- We invite proposals from potential speakers for talks and demonstrations. We are aiming for 20-minute talks with 5 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-hiw17.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. Program Committee ----------------- * Richard A. Eisenberg -- chair (Bryn Mawr College) * Adam Gundry (Well-Typed) * Bartosz Nitka (Facebook) * Wren Romano (X, formerly Google[x]) * Alejandro Serrano Mena (Utrecht University) * Jan Stolarek (University of Edinburgh) Contact ------- * Richard A. Eisenberg <rae(a)cs.brynmawr.edu>

1 1

Compilation time
by Deest, Gaël 04 Jul '17

04 Jul '17

Hi all, As you are probably well aware, GHC performance has been a growing concern over the last few years. Many Haskell programmers complain that build time has significantly increased over the last few releases. However, to our knowledge, there isn't much data available to substantiate this claim and the severity of these problems is not well known. That's why we would like to bring some anecdotal evidence to your attention that seems to indicate really major performance regressions. We stumbled upon the CI of the data-reify package, which is built against all GHC releases since 2010 : https://travis-ci.org/ku-fpg/data-reify tl;dr: Build time has gone from 1 min 32s for GHC 7.0 to 4 min 35s for GHC 8.2. The 8.2 release alone seems to have increased compilation time by almost 2 minutes, with the current development branch bringing only minor performance improvements. Of course, this single data point is not sufficient to establish how severe and widespread these problems are. More data could probably be gathered from other packages. However, it certainly matches our (subjective) experience and we felt important to report it to you. Regards, -- Gaël Deest Tweag I/O

4 3

Which stable GHC release is expected to have support for linear types?
by Wolfgang Jeltsch 30 Jun '17

30 Jun '17

Hi! The blog post on http://blog.tweag.io/posts/2017-03-13-linear-types.html says, “We are targeting a merge by the time of the 8.4 release of GHC.” Does this mean that GHC 8.4 is expected to have support for linear types, or does it mean that the merge should happen after a GHC 8.4 branch has been forked off from the HEAD branch, so that only GHC 8.6 will have support for linear types? All the best, Wolfgang

3 8

Windows broken
by Simon Peyton Jones 29 Jun '17

29 Jun '17

Help please! Suddenly my Windows build has stopped working. See below. What should I do? I'm totally stuck. This has never happened before. I get this: GHC path canonicalised to: c:/fp/ghc-8.0.2/bin/ghc checking build system type... x86_64-pc-msys checking host system type... x86_64-pc-msys checking target system type... x86_64-pc-msys Build platform inferred as: x86_64-unknown-mingw32 Host platform inferred as: x86_64-unknown-mingw32 Target platform inferred as: x86_64-unknown-mingw32 GHC build : x86_64-unknown-mingw32 GHC host : x86_64-unknown-mingw32 GHC target : x86_64-unknown-mingw32 LLVM target: x86_64-unknown-mingw32 checking for path to top of build tree... C:/code/HEAD configure: Checking for Windows toolchain tarballs... configure: Extracting Windows toolchain from archives (may take a while)... configure: In-tree MingW-w64 tree created configure: Making in-tree perl tree configure: In-tree perl tree created checking whether the C compiler works... no configure: error: in `/c/code/HEAD': configure: error: C compiler cannot create executables See `config.log' for more details Something wrong with the gcc.exe? Config.log has this gcc version 6.3.0 (Rev2, Built by MSYS2 project) configure:4950: $? = 0 configure:4939: C:/code/HEAD/inplace/mingw/bin/gcc.exe -V >&5 gcc.exe: error: unrecognized command line option '-V' gcc.exe: fatal error: no input files compilation terminated. configure:4950: $? = 1 configure:4939: C:/code/HEAD/inplace/mingw/bin/gcc.exe -qversion >&5 gcc.exe: error: unrecognized command line option '-qversion'; did you mean '--version'? gcc.exe: fatal error: no input files compilation terminated. configure:4950: $? = 1 configure:4970: checking whether the C compiler works configure:4992: C:/code/HEAD/inplace/mingw/bin/gcc.exe conftest.c >&5 configure:4996: $? = 1 configure:5034: result: no configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "The Glorious Glasgow Haskell Compilation System" | #define PACKAGE_TARNAME "ghc-8.3" | #define PACKAGE_VERSION "8.3" | #define PACKAGE_STRING "The Glorious Glasgow Haskell Compilation System 8.3" | #define PACKAGE_BUGREPORT "glasgow-haskell-bugs(a)haskell.org" | #define PACKAGE_URL "" | /* end confdefs.h. */ | | int | main () | { | | ; | return 0; | } configure:5039: error: in `/c/code/HEAD': configure:5041: error: C compiler cannot create executables

2 5

Thank you
by Simon Peyton Jones 28 Jun '17

28 Jun '17

Ryan I wanted to thank you for all the work you are putting into GHC at the moment. * You often produce nice small repro cases from other people's bug reports * you often bisect to the patch caused the bug; * your analysis is usually spot on; * you are actively maintaining the generics stuff * you contribute fixes In short, terrific. Thank you! Simon

1 0

hoopl dependency
by Simon Peyton Jones 26 Jun '17

26 Jun '17

Devs, Matko (an intern here at MSR) says Matko Bosnjak 19:02: Hi Simon, There's a 'bug' in some of the latest commits of ghc on git. When running ./build I get: Error: libraries/hoopl/LICENSE doesn't exist. Maybe you haven't done 'git submodule update --init'? at ./boot line 112, <PACKAGES> line 54. Someone removed the dependency on hoopl library, but hasn't removed it from the 'packages' file. What should he do? Simon

2 1

external interpreter failing on Mac
by Richard Eisenberg 19 Jun '17

19 Jun '17

Hi devs, It seems every test run through the external interpreter is failing for me on a Mac: =====> TH_mkName(ext-interp) 1 of 1 [0, 0, 0] cd "./TH_mkName.run" && "/Users/rae/ghc/ghc/inplace/test spaces/ghc-stage2" -c TH_mkName.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -XTemplateHaskell -package template-haskell -fexternal-interpreter -v0 Compile failed (exit code 1) errors were: ghc-iserv.bin: lookupSymbol failed in relocateSection (RELOC_GOT) /Users/rae/ghc/ghc/libraries/integer-gmp/dist-install/build/HSinteger-gmp-1.0.0.1.o: unknown symbol `___gmp_rands' ghc-stage2: unable to load package `integer-gmp-1.0.0.1' *** unexpected failure for TH_mkName(ext-interp) Any advice? My most recent commit from master is ef07010cf4f480d9f595a71cf5b009884522a75e from Wed Jun 7. I'm on IRC today if you want to iterate that way. Thanks! Richard

3 3

#13804
by Simon Peyton Jones 16 Jun '17

16 Jun '17

Ben I've just pushed a fix to Trac #13804. It may belong on the 8.2 branch too because it fixes a regression wrt 8.0. I can't test on my Unix box, because I'm away from it for a few days, but I've validated on windows. Can you just check it's ok, and fix up or revert if not? Thanks SImon

2 1

WordX/IntX wrap Word#/Int#?
by Michal Terepeta 15 Jun '17

15 Jun '17

Hi all, I've just noticed that all `WordX` (and `IntX`) data types are actually implemented as wrappers around `Word#` (and `Int#`). This probably doesn't matter much if it's stored on the heap (due to pointer indirection and heap alignment), but it also means that: ``` data Foo = Foo {-# UNPACK #-} !Word8 {-# UNPACK #-} !Int8 ``` will actually take *a lot* of space: on 64 bit we'd need 8 bytes for header, 8 bytes for `Word8`, 8 bytes for `Int8`. Is there any reason for this? The only thing I can see is that this avoids having to add things like `Word8#` primitives into the compiler. (also the codegen would need to emit zero-extend moves when loading from memory, like `movzb{l,q}`) If we had things like `Word8#` we could also consider changing `Bool` to just wrap it (with the obvious encoding). Which would allow to both UNPACK `Bool` *and* save the size within the struct. (alternatively one could imagine a `Bool#` that would be just a byte) I couldn't find any discussion about this, so any pointers would be welcome. :) Thanks, Michal PS. I've had a look at it after reading about the recent implementation of struct field reordering optimization in rustc: http://camlorn.net/posts/April%202017/rust-struct-field-reordering.html

4 6

RE: Removing Hoopl dependency?
by ning w 14 Jun '17

14 Jun '17

Thanks Ben. Both A and B (mentioned in Simon's reply) are good alternatives as long as existing Hoopl users are NOT forced to upgrade when they upgrade Cable or Stackage. Otherwise, we will see more forks of Hoopl. Once Cable and Stackage gain the multi-version capability, A and B can be merged back to Hoopl as a major release. In my experience, Hoopl based optimizations/program analyses tend to use a lot of memory, but they are also easy to verify. So it's still a useful tool in some special use cases. If the performance of Hoopl can be improved, it will certainly be more useful. Cheers, Ning *From:* Ben Gamari <ben(a)smart-cactus.org> *Date:* June 12, 2017 at 11:05:51 AM PDT *To:* Simon Peyton Jones <simonpj(a)microsoft.com>, Sophie Taylor < sophie(a)traumapony.org>, Michal Terepeta <michal.terepeta(a)gmail.com>, ghc-devs <ghc-devs(a)haskell.org>, Ning Wang <email(a)ningwang.org> *Cc:* Kavon Farvardin <kavon(a)cs.uchicago.edu> *Subject:* *RE: Removing Hoopl dependency?* Simon Peyton Jones via ghc-devs <ghc-devs(a)haskell.org> writes: Snip That would leave Sophie free to do (B) free of the constraints of GHC depending on it; but we could always use it later. Does that sound plausible? Do we know of any other Hoopl users? CCing Ning, who is currently maintaining hoopl and I believe has some projects using it. Ning, you may want to have a look through this thread if you haven't already seen it. You can find the previous messages in the list archive [1]. Cheers, - Ben [1] May messages: https://mail.haskell.org/piper mail/ghc-devs/2017-May/014255.html June messages: https://mail.haskell.org/piper mail/ghc-devs/2017-June/014293.html

1 0