February 2018 - ghc-devs

DoAndIfThenElse
by Harendra Kumar 22 Feb '18

22 Feb '18

Hi, I recently found a mention of DoAndIfThenElse extension somewhere. I looked inside the ghc user guide and could not find any such extension. Then I looked in the ghc man page, no mention. I googled and found a very sparse references to it here and there. Then I tried using the extension with ghc and ghc seems to accept it. What's the story behind this, why is it not documented but accepted? thanks, harendra

5 6

A (late-)demand analysis and w/w question
by Ömer Sinan Ağacan 21 Feb '18

21 Feb '18

Hi, I was recently looking at #6087. One of the cases that increased allocations (see comment:27) is when we do worker/wrapper to pass an `Int#` instead of `Int` when we need the boxed form in the function body. This causes redundant allocations because we already have the boxed version of the value but we passed it unboxed as a result of worker/wrapper. This raises the obvious (but maybe naive?) question of whether we could improve the demand analysis and/or worker/wrapper to avoid unpacking arguments when the argument is boxed again somewhere in the function body. Does this make sense? Has anyone tried this before? Thanks, Ömer

2 3

Re: [GHC DevOps Group] Release policies
by Boespflug, Mathieu 19 Feb '18

19 Feb '18

Hi Herbert, On 18 December 2017 at 12:22, Herbert Valerio Riedel <hvriedel(a)gmail.com> wrote: > Hi Mathieu, > > On Mon, Dec 18, 2017 at 12:03 PM, Boespflug, Mathieu <m(a)tweag.io> wrote: >> it's worth thinking about asking that >> the versions of all upstream packages only make it into GHC, at the >> behest of their respective maintainers, after a new release of >> upstream is made. > > Let me try to formulate the invariant such a procedure would demand: > > That would require a guarantee that the APIs provided by GHC (mostly > ghc-prim/base, but possibly more, including other boot libs; as well > as GHC's own behaviour) my package(s) rely upon are frozen to the > point that any such release of my packages advertising compatiblity > with the imminent GHC release will remain compatible with said final > GHC release. > > Is this something you're ready to guarantee? That's exactly it: a tradeoff. As you note, any package release now can't possibly anticipate all changes in future GHC. Furthermore, if a new GHC feature crucially depends on upstream but no upstream release is available yet, under this proposal merging the new GHC feature would need to be delayed. But on the other hand, if indeed GHC is to have more frequent releases, we can't have a GHC release perennially held up by upstream maintainers cutting their own releases one after the other, or worse still, releases happening *after* it already shipped in GHC as we just saw, or with breaking changes not announced to downstream tooling authors ahead of time. This is a problem that was brought up by Ben at ICFP, and again here. It's a problem relevant to the discussion at hand, which started as the result of upstream releases showing up on Hackage long after the release, and downstream tooling authors not afforded any advance notice to adapt. When this was brought up at ICFP, several GHC DevOps Group members recommended to Ben that he avoid needing *any* cooperation from upstream maintainers on the critical path towards a release. Of the packages you mention, base can't introduce breaking changes without a grace period. Are any upstream packages that closely tied to ghc-prim etc that a breaking change in the latter is likely between feature freeze and the release date? On the off-chance that a BC change does happen, package releases are cheap, so would that really be a problem? If a package is that closely tied to ghc-prim, base or any other boot lib, and conversely GHC is closely tied to it, then shouldn't that package just be part of the GHC codebase proper, rather than managed separately outside of GHC devs' control?

6 9

testsuite failures in DEBUG
by Richard Eisenberg 14 Feb '18

14 Feb '18

Hi devs, It seems our CI infrastructure has become too good. My workflow normally involves working with a DEBUG compiler, and then occasionally running the whole testsuite. I don't validate from scratch mid-patch, but it's good to know if I'm failing tests. With HEAD, I'm getting quite a few testsuite failures, and they all seem to be coming from ASSERTs, and they're all problems that I'm pretty sure I didn't cause. My full list of failures (I'm on Mac) is below, but after looking into 5-6 of them and finding only stuff that isn't my fault, I've given up. So: would it be possible to have our CI infrastructure validate DEBUG mode as well? Then it would be easy to spot where these failures are from. backpack/cabal/bkpcabal02/bkpcabal02.run bkpcabal02 [bad stderr] (normal) backpack/cabal/bkpcabal04/bkpcabal04.run bkpcabal04 [bad stderr] (normal) backpack/cabal/bkpcabal03/bkpcabal03.run bkpcabal03 [bad stderr] (normal) backpack/cabal/bkpcabal05/bkpcabal05.run bkpcabal05 [bad stderr] (normal) backpack/cabal/T14304/T14304.run T14304 [bad stderr] (normal) backpack/cabal/bkpcabal06/bkpcabal06.run bkpcabal06 [bad stderr] (normal) backpack/cabal/bkpcabal07/bkpcabal07.run bkpcabal07 [bad stderr] (normal) backpack/cabal/bkpcabal01/bkpcabal01.run bkpcabal01 [bad stderr] (normal) cabal/cabal04/cabal04.run cabal04 [bad stderr] (normal) cabal/T12733/T12733.run T12733 [bad stderr] (normal) cabal/cabal01/cabal01.run cabal01 [bad stderr] (normal) cabal/cabal03/cabal03.run cabal03 [bad stderr] (normal) cabal/cabal09/cabal09.run cabal09 [bad stderr] (normal) cabal/cabal08/cabal08.run cabal08 [bad stderr] (normal) cabal/cabal05/cabal05.run cabal05 [bad stderr] (normal) cabal/cabal06/cabal06.run cabal06 [bad stderr] (normal) dependent/should_compile/T12442.run T12442 [exit code non-0] (normal) dependent/should_compile/T12176.run T12176 [exit code non-0] (normal) driver/T3007/T3007.run T3007 [bad stderr] (normal) gadt/T12087.run T12087 [stderr mismatch] (normal) ghci/scripts/ghci063.run ghci063 [bad stderr] (ghci) indexed-types/should_fail/T13877.run T13877 [stderr mismatch] (normal) parser/should_fail/NumericUnderscoresFail0.run NumericUnderscoresFail0 [stderr mismatch] (normal) parser/should_fail/NumericUnderscoresFail1.run NumericUnderscoresFail1 [stderr mismatch] (normal) patsyn/should_compile/T13350/T13350.run T13350 [bad stderr] (normal) pmcheck/should_compile/T11195.run T11195 [exit code non-0] (normal) polykinds/T14174a.run T14174a [exit code non-0] (normal) printer/T13050p.run T13050p [bad exit code] (normal) safeHaskell/check/pkg01/safePkg01.run safePkg01 [bad stderr] (normal) simplCore/should_compile/T13025.run T13025 [bad stderr] (normal) simplCore/should_compile/T13410.run T13410 [exit code non-0] (normal) typecheck/T13168/T13168.run T13168 [bad stderr] (normal) typecheck/bug1465/bug1465.run bug1465 [bad stderr] (normal) typecheck/should_compile/holes2.run holes2 [exit code non-0] (normal) typecheck/should_compile/valid_substitutions.run valid_substitutions [exit code non-0] (normal) typecheck/should_compile/holes3.run holes3 [stderr mismatch] (normal) typecheck/should_compile/holes.run holes [stderr mismatch] (normal) typecheck/should_compile/T13050.run T13050 [exit code non-0] (normal) typecheck/should_compile/T13822.run T13822 [exit code non-0] (normal) typecheck/should_compile/T14590.run T14590 [exit code non-0] (normal) typecheck/should_compile/T13032.run T13032 [stderr mismatch] (normal) typecheck/should_fail/T7175.run T7175 [stderr mismatch] (normal) Thanks! Richard

3 3

Looking for GSoC Mentor
by Andreas Klebinger 14 Feb '18

14 Feb '18

Hello Everyone, I'm looking for a mentor for a GSoC Project/Proposal. The whole idea revolves around: * Getting hot path information from static analysis and user annotations. * Making sure it's not destroyed by optimization passes. * Using it to generate better code where applicable. See also: #14672: Make likelihood of branches/conditions available throughout the compiler. Towards these goals I would like for GSoC: * Land https://phabricator.haskell.org/D4327(Branchweights in STG and Cmm) + It might be ready before then. But it's a prerequisite so worth listing here. * Design and implement a way for users to: + Mark hot paths in Haskell code. + Push the information through the passes (up to STG) on a best effort basis. STG and beyond is part of the diff above. + The current backend already uses this information in some places, so this alone should lead to small but consistent gains. + I don't plan to add additional optimizations unless there is time left at the end. Where I think I will need help/experience from a mentor is: * Frontend questions: I haven't looked at GHC's parser/renamer yet so while this is surmountable I expect some questions to arise there. * Design questions/feedback: Things like: + How should the user be able to give this information. + What should be flag controlled? What always on? + Things like compile time/executable speed tradeoffs. ... * Potentially the simplifier: I've looked into it briefly as originally D4327 was aimed at the core stage instead of stg. There doesn't seem to be a lot that could mess with hot path information/branchweights. But I haven't worked on the simplifier before and it seems like a good place for unexpected issues to arise. * If this involves the proposal process then also guidance there. For myself: * I'm studying at TU Vienna (Software & Information Engineering) and am close to finishing my undergrad. Located in Austria (UTC+1) * I have contributed a few small changes to GHC throughout last year. See AndreasK on Phab/Trac. * If you want to know more contact me! If you are interested in mentoring me or looking for more details feel free to contact me at klebinger.andreas(a)gmx.at <mailto:klebinger.andreas@gmx.at>or look for AndreasK in #ghc Best Regards Andreas

1 0

User constructed types with new Data.Typeable and Data.Reflection
by Development 13 Feb '18

13 Feb '18

Hey guys I have a (hopefully quick) question. With the new `Data.Typeable` and `Data.Reflection` in base 4.10 have we really lost the ability for users to compose `TypeRep`’s? I was using `Data.Typeable` before (mainly `mkTyConApp`). But in the new base 4.10 I cannot find any way to achieve the same goal. I have read the wiki page Typeable and Typeable/BenGamari and neither explicitly mentions the removal of `mkTyConApp` and similar facilities. In fact the latter mentions potential implementations for user constructed type applications twice with `mkTrApp` at the beginning of the page and `mkApp` at the end. Furthermore the documentation for `Typeable` (and `Reflection`) also never mentions the fact that this functionality was removed. My question is this: Is this intentional? Is there now a consensus that there should not be user constructed types? Or is there some subtile issue that I’m missing wich prevents user constructed types for now or always? Thanks in advance guys. Best regards. Justus

3 4

Re: [Haskell-cafe] GHC 8.2.2 for WSL Ubuntu 16.04
by Herbert Valerio Riedel 13 Feb '18

13 Feb '18

Hello *, Even though WSL may eventually address this issue for good, I've setup a new WSL-optimised flavour of my PPA for Ubuntu 16.04 LTS https://launchpad.net/~hvr/+archive/ubuntu/ghc over at https://launchpad.net/~hvr/+archive/ubuntu/ghc-wsl I don't have experience myself with Ubuntu on WSL, but it should be simply a matter of using sudo add-apt-repository ppa:hvr/ghc-wsl sudo apt-get update and then sudo apt-get install ghc-8.2.2-prof cabal-install-head Then simply add `/opt/ghc/bin` to your `$PATH` (see instructions at https://launchpad.net/~hvr/+archive/ubuntu/ghc ) There are also builds of GHC 8.0.2 and GHC 8.4.1-alpha (may still be building as of writing) in this new ghc-for-wsl PPA. I'd appreciate if somebody could test whether these GHC binaries work as intended on the non-insider Windows 10 builds and let me know. Cheers, Herbert On Tue, Feb 13, 2018 at 12:21 PM, Yitzchak Gale <gale(a)sefer.org> wrote: > I wrote: >>> I have made available a build of GHC 8.2.2 with the config option: >>> --disable-large-address-space >>> [2] https://github.com/Microsoft/WSL/issues/1671 > > Shao Cheng wrote: >> Thank you! A simpler fix for WSL ghc users is upgrading to fast ring of >> insider builds, the mmap overhead is much lower and ghc startup lag is >> barely noticable. > > Thanks, that's good news. I can't use an insider build - I need to be on > standard Windows in order to support our customers. The latest reports > in the GitHub issue seemed to indicate that the slowness is still quite > significant even on insider builds. I'm glad to hear you say that this is no > longer true. I am looking forward to regular GHC binary tarballs working > normally on regular WSL sometime in the near future. > > Yitz > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post.

1 0

StgLint worth maintaining?
by Ömer Sinan Ağacan 10 Feb '18

10 Feb '18

Hi, I've been looking into some StgLint-related tickets: - #13994: Found a StgLint problem and fixed, there's another problem waiting to be fixed. Both related with the fact that after unarisation we lose even more typing information and type checks needs to be relaxed. - #14116: StgLint failed to look through newtypes, and because coercions are removed at that point it failed to type check. Solution was to relax type checks. - #5345: Because `unsafeCoerce# is operationally no-op, and we don't have coercions in STG, StgLint can't type check at all. The commit message notes: > Fundamentally STG Lint is impossible, because unsafeCoerce# > can randomise all the types. > This patch does a bit of fiddle faddling in StgLint which > makes it a bit better, but it's a losing battle. - #14117: Related with StgLint not keeping up with recent changes (join points), because it's not enabled by default in tests/validate. - #14118: Related with the fact that pre- and post-unarise we have different invariants in STG. Solution was to add a "unarise" parameter and do different checks based on that. - #14120: Again type checking errors. Commit for #14116 also fixes this. The commits compares `typePrimRep`s of types instead of comparing actual types (even this is not enough, see #13994). All this of course took time to debug. In addition, the new `StgCSE` pass makes transformations that trigger case alternative checks (and probably some other checks) because scrutinee and result won't have same types after the transformation described in `Note [Case 2: CSEing case binders]`. There's also this comment in StgLint.hs WARNING: ~~~~~~~~ This module has suffered bit-rot; it is likely to yield lint errors for Stg code that is currently perfectly acceptable for code generation. Solution: don't use it! (KSW 2000-05). It seems like it hasn't been used since 2000. All this suggests that - Checks related to types are impossible in StgLint. (see e.g. commit messages in #5345, #1420, transformations done by unariser and StgCSE) - It's not enabled since 2000, which I think means that it's not needed. This makes me question whether it's worth maintaining. Maybe we should just remove it. If we still want to keep we should decide on what it's supposed to do. Only invariants I can think of are: - After unarise there should be no unboxed tuple and sum binders. unarise is a simple pass and does same thing to all binders, there are no tricky cases so I'm not sure if we need to check this. - Variables should be defined before use. I again don't know if this should be checked, could this be useful for StgCSE? So I think we should do one of these: 1. Remove StgLint. 2. Rewrite it to only check these two and nothing else, enable it in validate (and in other build flavours that enable CoreLint). What do you think? If you think we should keep StgLint, can you think of any other checks? If we could reach a consensus I'm hoping to update StgLint (or remove it). Thanks, Ömer

2 2

RE: about GHC API: Looking up names
by Simon Peyton Jones 09 Feb '18

09 Feb '18

Ranjit Have you read Note [The equality types story] in compiler/prelude/TysPrim? As you’ll see (~) is actually a class; the equality predicate is (~#). There doesn’t seems to be a named-function predicate that checks for it explicitly, but if you grep for eqTyCon you’ll see lots of tests for it. I’m sure these tests could be tideied up into a smaller collection of predicates. Simon From: rjhala(a)eng.ucsd.edu [mailto:rjhala@eng.ucsd.edu] On Behalf Of Ranjit Jhala Sent: 09 February 2018 04:41 To: Simon Peyton Jones <simonpj(a)microsoft.com> Subject: Re: about GHC API: Looking up names Dear Simon, still working on the above, but hit an odd problem on the way. How can I "test for" (i.e. write a function of type `Type -> Bool`) that returns `True` for values (i.e. `Type`s) that print out as: typ ~ GHC.Types.Int<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2FGHC.Types.I…> or with, which some more detail, looks like (~ (TYPE LiftedRep) typ GHC.Types.Int<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2FGHC.Types.I…>) I would have thought that `Type.isEqPred` or `Type.isNomEqPred` described here https://downloads.haskell.org/~ghc/8.2.1/docs/html/libraries/ghc-8.2.1/src/…<https://na01.safelinks.protection.outlook.com/?url=https:%2F%2Fdownloads.ha…> would work, but apparently not? Any clues? Thanks! - Ranjit. On Thu, Feb 1, 2018 at 8:25 AM, Ranjit Jhala <jhala(a)cs.ucsd.edu<mailto:jhala@cs.ucsd.edu>> wrote: Will do! Best, Ranjit. On Thu, Feb 1, 2018 at 5:20 AM, Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: I’m glad you are un-glued, but it smells wrong to me and your solution seems like a workaround for a bug, not the Right Path. Could you make a ticket with a repro case? Thanks! Simon From: rjhala(a)eng.ucsd.edu<mailto:rjhala@eng.ucsd.edu> [mailto:rjhala@eng.ucsd.edu<mailto:rjhala@eng.ucsd.edu>] On Behalf Of Ranjit Jhala Sent: 31 January 2018 19:14 To: Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> Subject: Re: about GHC API: Looking up names Dear Simon, No worries, I was able to figure it out, or at least work around it. > It’s very mysterious that declaring it in an > instance decl would make any difference. It looks like that is exactly what is happening, but perhaps by design? (I saw there was something called an `ImplicitTyThing` that are not in the top-level scope, so I figured that perhaps these instance declarations were "implicit" and hence not available?) Nevertheless, I was able to work around the issue by using `tcGetFamInstEnvs` to get the `FamInstEnv` and from that, making my own lookup environment (comprising the TyCon and DataCon for the family instances.) This works for my purposes, but if the above is a possible bug, I can try to make a small test case? Thanks! - Ranjit. On Wed, Jan 31, 2018 at 1:47 AM, Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: Hi Ranjit That does sound odd. You should ask on ghc-devs too… though you may already have done that. hscTcRnLookupName doesn’t do anything fancy: it just looks up the Name in the type environment. It’s very mysterious that declaring it in an instance decl would make any difference. I suppose you could somehow have gotten hold of the wrong Name. If I was debugging it, I’d start spitting out traces showing the type environment it is looking up in, to see what is there and what is not. If you make a small standalone test case (e.g. a tiny client of the GHC API that demonstrates the problem) that could enable others to reproduce and help you. Or, I guess, we could do a Skype chat with you trying things locally. I wish I could help more Simon From: rjhala(a)eng.ucsd.edu<mailto:rjhala@eng.ucsd.edu> [mailto:rjhala@eng.ucsd.edu<mailto:rjhala@eng.ucsd.edu>] On Behalf Of Ranjit Jhala Sent: 26 January 2018 02:12 To: Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> Subject: Q: about GHC API: Looking up names Dear Simon, I have a question about the GHC API I wonder you can help with? Suppose `Library.hs` is has the constructors defined in the simple top-level style: ``` data EntityField typ where BlobXVal :: EntityField Int BlobYVal :: EntityField Int ``` Then when analyzing `Client.hs` (that imports `Library`), the lookup function `hscTcRcLookupName` WORKS just fine to give me the `TyThing` corresponding to the name “BlobXVal”. However, if instead, Library.hs defines the constructors within an instance: ``` instance PersistEntity Blob where data EntityField Blob typ where BlobXVal :: EntityField Blob Int BlobYVal :: EntityField Blob Int ``` then, when analyzing Client.hs, the `hscTcRcLookupName` function FAILS to resolve the name. Clearly there is some difference in how `hscTcRcLookupName` works in these two cases. Does you know what it is? Thanks in advance!

1 0

Can't typeset docs
by Simon Peyton Jones 08 Feb '18

08 Feb '18

When I have BUILD_SPHINX_HTML = YES BUILD_SPHINX_PDF = YES I get this error in my build. Any ideas? I think Sphinx is up to date. Thanks Simon sh validate --fast --no-clean using THREADS=33 make: Entering directory '/5playpen/simonpj/HEAD-3/utils/checkUniques' ./check-uniques.py ../.. make: Leaving directory '/5playpen/simonpj/HEAD-3/utils/checkUniques' ===--- building phase 0 make --no-print-directory -f ghc.mk phase=0 phase_0_builds make[1]: Nothing to be done for 'phase_0_builds'. ===--- building phase 1 make --no-print-directory -f ghc.mk phase=1 phase_1_builds make[1]: Nothing to be done for 'phase_1_builds'. ===--- building final phase make --no-print-directory -f ghc.mk phase=final all /usr/bin/sphinx-build -b html -d docs/users_guide/.doctrees-html -D latex_paper_size=letter docs/users_guide docs/users_guide/build-html/users_guide /usr/bin/sphinx-build -b latex -d docs/users_guide/.doctrees-pdf -D latex_paper_size=letter docs/users_guide docs/users_guide/build-pdf/users_guide /usr/bin/sphinx-build -b man -d docs/users_guide/.doctrees-man docs/users_guide docs/users_guide/build-man Running Sphinx v1.3.6 making output directory... Running Sphinx v1.3.6 Exception occurred: making output directory... Exception occurred: Running Sphinx v1.3.6 making output directory... Exception occurred: File "conf.py", line 13, in <module> from ghc_config import extlinks, version ImportError: No module named ghc_config File "conf.py", line 13, in <module> from ghc_config import extlinks, version ImportError: No module named ghc_config File "conf.py", line 13, in <module> from ghc_config import extlinks, version ImportError: No module named ghc_config The full traceback has been saved in /tmp/sphinx-err-d_zVKs.log, if you want to report the issue to the developers. Please also report this if it was a user error, so that a better error message can be provided next time. A bug report can be filed in the tracker at <https://github.com/sphinx-doc/sphinx/issues>. Thanks! The full traceback has been saved in /tmp/sphinx-err-hbXcSK.log, if you want to report the issue to the developers. Please also report this if it was a user error, so that a better error message can be provided next time. A bug report can be filed in the tracker at <https://github.com/sphinx-doc/sphinx/issues>. Thanks! The full traceback has been saved in /tmp/sphinx-err-lmyy8H.log, if you want to report the issue to the developers. Please also report this if it was a user error, so that a better error message can be provided next time. A bug report can be filed in the tracker at <https://github.com/sphinx-doc/sphinx/issues>. Thanks! docs/users_guide/ghc.mk:28: recipe for target 'docs/users_guide/build-man/ghc.1' failed make[1]: *** [docs/users_guide/build-man/ghc.1] Error 1 make[1]: *** Waiting for unfinished jobs.... docs/users_guide/ghc.mk:16: recipe for target 'docs/users_guide/users_guide.pdf' failed make[1]: *** [docs/users_guide/users_guide.pdf] Error 1 docs/users_guide/ghc.mk:16: recipe for target 'docs/users_guide/build-html/users_guide/index.html' failed make[1]: *** [docs/users_guide/build-html/users_guide/index.html] Error 1 Makefile:122: recipe for target 'all' failed make: *** [all] Error 2 simonpj@cam-05-unx:~/5builds/HEAD-3$

2 3