- Glasgow-haskell-users

Scoped Type Variables discussion forum [was: open up the issues tracker on ghc-proposals]
by Anthony Clayden 09 May '18

09 May '18

This thread is a discussion about discussions, not the discussion itself ;-) I'm cc'ing to the cafe; but I'd prefer replies to come to glasgow-haskell-users. >> I can volunteer to at least scrape together all the objections to ScopedTypeVariables as currently. It's not yet a proposal, so not on github. Start a wiki page? A cafe thread? (It'll get lost.) A ghc-users thread? (It'll get ignored.) > ... don’t care what forums or list or whatever. As long as it’s collated and such > It could even be on the prime issue tracker for prime proposals. Just that it’s written down :) Thanks Carter, but I understand Haskell Prime to be to assess mature/stable proposals (preferably already delivered as extensions). This discussion is at first going to be more exploratory: * likes and dislikes about ScopedTypeVariables as currently. * confusions experienced by users (especially newbies) -- although absolute newbies wouldn't be using it(?), so intermediates? * feedback from those teaching Haskell. * wild ideas for possible alternative designs. * possible improvements to the current design. * I think we're all agreed that ScopedTypeVariables should have been in Haskell from the beginning; but it wasn't, so now we have to worry about backwards compatibility for programs that worked around the omission. Or do we? What code would break? How much pain would that cause? * anything else? > We have lots of forums, but your point is that certain sorts of discussions never get going with the right audience – you especially point to “confused beginners”. > ... It’s quite a challenge because beginners tend not to be vocal, and yet they are a crucial set of Haskell users. Every Haskell user started as a beginner. On this particular topic, there's plenty of confused people asking questions on StackOverflow. (Heads up: they're especially asking why they need explicit `forall` whereas in reguar Haskell that 'intermediates' see, the forall is implicit.) Can other people point me to questions/likes/dislikes on other forums? Reddit for example. If you've read this far, you now understand what we're trying to cover. It's going to be random/varied thoughts at first, then perhaps coalescing to an approach or two. At that point a formal proposal on github proper; and the random stuff might be interesting background but will essentially get archived/thrown away. I do agree with David's suggestion that github Issue tracker looks like a suitable solution. We can write formatted code and text. We can add links and references. What do others think? Joachim has opened up Issues tracker, as a try-out. If using it doesn't work out, that's fine and in keeping with my "thrown away" above. Also where else should I post links to this message to 'advertise' the thread? I don't reddit much, so if that's suitable, please someone post there. Thank you AntC

2 1

Re: Open up the issues tracker on ghc-proposals
by Anthony Clayden 05 May '18

05 May '18

> On May 1, 2018, at 2:24 PM, David Feuer <david.feuer at gmail.com> wrote: > > Sometimes, a language extension idea could benefit from some community discussion before it's ready for a formal proposal. Can I point out it's not only ghc developers who make proposals. I'd rather you post this idea more widely. As a datapoint, I found ghc-users and the café just fine for those discussions. Ghc-users seems to have very low traffic/is rather wasted currently. And I believe a lot of people pre-discuss on reddit. For ideas that have been on the back burner for a long time, there's often wiki pages. (For example re Quantified Constraints.) > I'd like to propose that we open up the GitHub issues tracker for ghc-proposals to serve as a place to discuss pre-proposal ideas. Once those discussions converge on one or a few specific plans, someone can write a proper proposal. I'm not against that. There gets to be a lot of cruft on some discussions about proposals, so I'd expect we could archive it all once a proposal is more formalised. AntC

5 8

[ANNOUNCE] GHC 8.4.2 released
by Ben Gamari 01 May '18

01 May '18

Hello everyone, The GHC team is pleased to announce the availability of GHC 8.4.2. The source distribution, binary distributions, and documentation for this release are available at https://downloads.haskell.org/~ghc/8.4.2 This release is a bug-fix release, fixing numerous regressions and bugs present in GHC 8.4.1. These include: * A regression resulting in some uses of `Control.Exception.evaluate` to be inappropriately optimised away (see #13930) * A regression resulting in segmentation faults of programs compiled with profiling (#14705) * A bug causing runtime system panics while running programs with retainer profiling (#14947) * The configure scripts now accepts a `--disable-dtrace` option, again allowing GHC to be bootstrapped on FreeBSD (#15040) * The version number of the `base` package has been bumped to 4.11.1.0 to reflect the addition of the `GHC.IO.FixIOException` type. This interface was added in 8.4.1 but the version bump was missed due to an oversight. * Support for DWARF debug information has been significantly improved (#14894, #14779) A more thorough list of the changes in this release can be found in the release notes, https://downloads.haskell.org/~ghc/8.4.2/docs/html/users_guide/8.4.2-notes.… Thanks to everyone who has contributed to developing, documenting, and testing this release! As always, let us know if you encounter trouble. How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language. 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. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://ghc.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: http://ghc.haskell.org/trac/ghc/wiki/Contributors 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 accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://ghc.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; 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-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 #haskell on IRC, 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

Accessing 'Annotations' of modules in external packages
by Ranjit Jhala 20 Apr '18

20 Apr '18

Hi all, I'm looking for some help using the GHC API to access the 'Annotations' (created using the 'ANN' mechanism) within modules of *external* packages i.e. non-home modules.Currently I'm using hscEPS :: HscEnv -> IO ExternalPackageState and then using the field eps_PIT :: !PackageIfaceTable and from there, accessing the mi_anns :: [IfaceAnnotation] field of the data ModIface stored in the PackageIfaceTable but this ends in an unfortunate: ``` panic! (the 'impossible' happened) (GHC version 8.2.2 for x86_64-apple-darwin): No mi_anns in PIT Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug ``` Perhaps this is because, as the documentation for `mi_anns` says: Annotations NOT STRICT! we read this field lazily from the interface file but I am not sure how to proceed at this point? Do I need a _different_ HscEnv? Or perhaps I need to set up/initialize the HscEnv separately? Any pointers would be most welcome! Thanks! Ranjit.

2 1

.ghci runs after flag parsing?
by Evan Laforge 05 Apr '18

05 Apr '18

I just noticed that it appears flag parsing happens before executing .ghci. And sure enough, looking at the source, GHCi.UI.runGHCi executes the dot files, which is definitely after all the dynflags parsing stuff in Main. This means that if your .ghci has a -Wall, you can't turn off warnings from the command line. You have to prepend ":set " to the flags and make a local ./.ghci, or pass -ghci-script. I assume this has how it's already been, and I'm surprised it's taken me this long to notice this! Is there a good reason to do it this way, or is it just the way it's always been and no one complained? It's surprising to me because I think most programs do it the other way. E.g. when you start your shell, settings on the command line will override your .zshrc or whatever. zsh for one doesn't seem to clearly document this, but experimenting seems to indicate that is so. I can put all my flags in a -ghci-script without too much trouble, it's just a surprising default.

1 0

8.4.1 ghci findings
by Evan Laforge 23 Mar '18

23 Mar '18

I just filed this bug: #14963: ghci -fdefer-type-errors can't run IO action from another module https://ghc.haskell.org/trac/ghc/ticket/14963 It seems like -fdefer-type-errors and ghci just don't get along at all now. But on the good news side, ghci reloading a changed module in 8.4.1 is much much faster than 8.0.2. I don't know who did that, but good work! Reload being instant instead of having to wait a second or so makes a big difference.

1 0

ghc 8.0.2 vs 8.4.1 compilation time and performance
by Evan Laforge 21 Mar '18

21 Mar '18

I just upgraded from 8.0.2 to 8.4.1, and I took the opportunity to do a few informal compile time and run time tests. There's been a lot of talk about compile time regressions, so maybe these will be of interest, informal as they are. I wound up skipping 8.2.1 due to https://ghc.haskell.org/trac/ghc/ticket/13604, but I could still test with 8.2 perfectly well. Just haven't done it yet. In this context, RunTests is more code with no optimization (and -fhpc, if it matters). debug/seq and opt/seq are the same code but with no optimization and -O respectively. I found that -O2 hurt compile time but didn't improve run time, but it's been a long time so I should run that experiment again. compile times: OS X, macbook pro: RunTests 549.10s user 118.45s system 343% cpu 3:14.53 total 8.0.2 RunTests 548.71s user 117.10s system 347% cpu 3:11.78 total 8.0.2 RunTests 450.92s user 109.63s system 343% cpu 2:43.13 total 8.4.1 RunTests 445.48s user 107.99s system 341% cpu 2:42.19 total 8.4.1 debug/seq 284.47s user 55.95s system 345% cpu 1:38.58 total 8.0.2 debug/seq 283.33s user 55.27s system 343% cpu 1:38.53 total 8.0.2 debug/seq 220.92s user 50.21s system 337% cpu 1:20.32 total 8.4.1 debug/seq 218.39s user 49.20s system 345% cpu 1:17.47 total 8.4.1 opt/seq 732.63s user 70.86s system 338% cpu 3:57.30 total 8.0.2 opt/seq 735.21s user 71.48s system 327% cpu 4:06.31 total 8.0.2 opt/seq 785.12s user 65.42s system 327% cpu 4:19.84 total 8.4.1 opt/seq 765.52s user 64.01s system 321% cpu 4:18.29 total 8.4.1 Linux, PC: RunTests 781.31s user 58.21s system 363% cpu 3:50.70 total 8.0.2 RunTests 613.11s user 49.84s system 357% cpu 3:05.52 total 8.4.1 debug/seq 429.44s user 31.34s system 362% cpu 2:07.03 total 8.0.2 debug/seq 329.67s user 23.86s system 352% cpu 1:40.38 total 8.4.1 opt/seq 1277.20s user 45.85s system 358% cpu 6:08.68 total 8.0.2 opt/seq 1339.73s user 39.87s system 341% cpu 6:43.50 total 8.4.1 So it looks like non-optimized compile times have gotten significantly better since 8.0.2. However, optimized has gotten a little worse, but not much. The performance numbers are a bit more disappointing. At first it appeared that allocation went down in 8.4.1 while overall time is up significantly. However, the 8.4.1 used newer dependencies, so to try to control for those, I tested again after using a cabal freeze from the 8.4.1 test. Of course I had to remove the ghc distributed packages, like container and 'ghc' itself, but the rest of the deps should be the same. Those have the 'libs' suffix on Linux. >From that, it looks like the improved memory in 8.4.1 was due to external dependencies, and in fact 8.4.1 bumped memory usage up again. Ow. In the graphs, 'score' is just the input file. 'max mb' and 'total mb' and 'prd' come from the post-run GC report, specifically '* bytes maximum residency', '* bytes allocated in the heap', and productivity fields. 'derive', 'lily' and 'perform' are just different kinds of processes. They are CPU time bracketing the specific action, after initialization, and the range is min and max over 6 runs, so no fancy criterion-like analysis. Each run is a separate process, so they should be independent. I was hoping for some gains due to the join points stuff, but it kind of looks like things get worse across the board. I don't know why productivity goes down so much, and I don't know why the effect seems so much worse on OS X. Of course the obvious next step is to see where 8.2.1 lies, but I thought I'd see if there's interest before going to the trouble. Of course, I should track down the regressions for my own purposes, but it's a bit of a daunting task. The step of reducing to a minimal example seems a lot harder for performance than for a bug! Probably some old fashioned SCC annotations await me, but that can be a long and confusing process. OS X, macbook pro: score max mb total mb prd derive lily perform ghc 6 72.26 3279.22 0.88 0.79~0.84 0.70~0.74 0.31~0.33 8.0.2 6 76.63 3419.20 0.58 1.45~1.59 1.05~1.07 0.33~0.36 8.4.1 bloom 70.69 2456.14 0.89 1.32~1.36 0.15~0.16 8.0.2 bloom 67.86 2589.97 0.62 1.94~1.99 0.20~0.22 8.4.1 cerucuk-punyah 138.01 10080.55 0.93 6.98~7.16 1.24~1.30 8.0.2 cerucuk-punyah 130.78 9617.35 0.68 8.91~9.22 1.57~1.68 8.4.1 hex 32.86 2120.95 0.91 0.76~0.88 0.16~0.19 8.0.2 hex 32.67 2194.82 0.66 1.09~1.16 0.28~0.30 8.4.1 p1 67.01 4039.82 0.92 2.63~2.73 0.47~0.50 8.0.2 p1 64.80 3899.85 0.68 3.35~3.43 0.58~0.59 8.4.1 viola-sonata 69.32 6083.65 0.92 2.48~2.56 2.07~2.13 0.25~0.26 8.0.2 viola-sonata 66.76 6120.26 0.68 3.32~3.43 2.90~2.93 0.32~0.34 8.4.1 Linux, PC: score max mb total mb prd derive lily perform ghc 6 79.76 3310.69 0.89 0.88~0.89 0.73~0.75 0.27~0.27 8.0.2 6 72.21 3421.45 0.90 0.87~0.87 0.72~0.79 0.28~0.28 8.0.2 libs 6 76.56 3419.05 0.77 1.16~1.17 0.87~0.93 0.33~0.33 8.4.1 bloom 69.82 2461.95 0.89 1.35~1.36 0.17~0.17 8.0.2 bloom 63.45 2554.89 0.90 1.33~1.35 0.18~0.18 8.0.2 libs bloom 67.79 2589.85 0.79 1.64~1.65 0.20~0.20 8.4.1 cerucuk-punyah 137.05 10113.41 0.94 7.44~7.50 1.31~1.33 8.0.2 cerucuk-punyah 128.09 10278.03 0.94 7.50~7.55 1.37~1.38 8.0.2 libs cerucuk-punyah 131.20 9617.22 0.84 7.35~7.40 1.49~1.50 8.4.1 hex 32.02 2096.87 0.92 0.73~0.74 0.18~0.18 8.0.2 hex 32.05 2200.30 0.91 0.73~0.80 0.19~0.19 8.0.2 libs hex 32.46 2144.22 0.83 0.89~0.90 0.20~0.20 8.4.1 p1 65.88 4054.66 0.93 2.84~2.87 0.49~0.50 8.0.2 p1 62.60 4127.68 0.94 2.83~2.92 0.51~0.51 8.0.2 libs p1 64.72 3899.72 0.81 2.80~2.81 0.54~0.55 8.4.1 viola-sonata 68.68 6086.49 0.93 2.55~2.56 2.10~2.12 0.27~0.27 8.0.2 viola-sonata 65.05 6212.57 0.93 2.52~2.55 2.07~2.16 0.28~0.28 8.0.2 libs viola-sonata 66.85 6120.15 0.83 2.91~2.92 2.48~2.51 0.30~0.31 8.4.1

1 0

"strange" error
by asyropoulos＠aol.com 15 Mar '18

15 Mar '18

Hello, I have compiled the latest veersion of ghc under OpenIndiana (Solaris) and now I am trying to compile cabal. I downloaded the source code from https://www.haskell.org/cabal/download.html and I tried to compile. I used the bootstrap.sh script bit it failed: Configuring cabal-install-2.0.0.1... Setup: Encountered missing dependencies: HTTP >=4000.1.5 && <4000.4, async >=2.0 && <3, cryptohash-sha256 ==0.11.*, hackage-security >=0.5.2.2 && <0.6, hashable >=1.0 && <2, tar >=0.5.0.3 && <0.6 Error during cabal-install bootstrap: Configuring the cabal-install package failed. The script downloaded all these packages so I tried to see why they fail: $ cd HTTP-4000.3.7 $ ls CHANGES HTTP.cabal Network test dist LICENSE Setup.lhs $ runhaskell Setup configure Configuring HTTP-4000.3.7... Setup: Encountered missing dependencies: base >=4.3.0.0 && <4.11 Of course this package is already installed and this means that for some reason it cannot find it. It is quite possible that I am doing something stupid but I would like to know how can I proceed? Thanks in advance for your help/assistance. A.S. -- Apostolos Syropoulos Xanthi, Greece

1 0

[ANNOUNCE] GHC 8.4.1 released
by Ben Gamari 14 Mar '18

14 Mar '18

The GHC developers are very happy to announce the 8.4.1 release of Glasgow Haskell Compiler. Binary and source distributions can be found at https://downloads.haskell.org/~ghc/8.4.1/ This is the third major release in the GHC 8 series. As such, the focus of this release is performance, stability, and consolidation. Consequently numerous cleanups can be seen throughout the compiler including, * Further refinement of TypeInType, including significant improvements in error messages. * Improvements in code generation resulting in noticable performance improvements in some types of programs. * Core library improvements, including phase 2 of the Semigroup/Monoid proposal * Many improvements to instance deriving * The resolution of nearly 300 other tickets A more thorough list of the changes in this release can be found in the release notes, https://downloads.haskell.org/~ghc/8.4.1/docs/html/users_guide/8.4.1-notes.… There are a few changes in release-engineering matters that should be noted, * This is GHC's first release on it's new, accelerated release schedule. From now on GHC will produce one release every six months. * While we typically strive to produce OpenBSD builds, the gcc shipped with OpenBSD 6.1 is unfortunately too old to compile this release. * FreeBSD builds are still in progress This release has been the result of approximately six months of work by over one hundred code contributors. Thanks to everyone who has helped in writing patches, testing, reporting bugs, and offering feedback over the last year. As always, let us know if you encounter trouble. How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language. 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. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://ghc.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: http://ghc.haskell.org/trac/ghc/wiki/Contributors 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 accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://ghc.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; 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-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 #haskell on IRC, 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

5 8

Re: [ANNOUNCE] GHC 8.4.1 released
by asyropoulos＠aol.com 08 Mar '18

08 Mar '18

Hello, I tried to compile the latest bits on OpenIndiana (the open version of Solaris) and compilation never starts because: checking target system type... i386-pc-solaris2.11 Build platform inferred as: i386-unknown-solaris2 Host platform inferred as: i386-unknown-solaris2 Target platform inferred as: i386-unknown-solaris2 Unknown OS solaris2.11 The configure script mentions Solaris... On my system I get $ uname -m i86pc $ uname -r 5.11 $ uname -s SunOS $ uname -v illumos-87446a5213 Any idea that migh help me go beyond this point? Thanks in advance! A.S. -- Apostolos Syropoulos Xanthi, Greece

2 1