January 2016 - ghc-devs

Re: Special treatment of family and role in the parser
by Jan Stolarek 21 Jan '16

21 Jan '16

I'll take a look at the parser, see if we can do better. > I also suggest that keywords introduced by GHC extensions should be lexed as keywords regardless > of whether extension is enabled or not: this way users won't get spurious errors if they > suddenly enable extension and it turns out that some of their identifiers have become keywords. I would be cautious here. Patch I am working on right now will use "kind" as a reserved identifier. It will only be allowed after `data` keyword. Making it a reserved word everywhere would be a major issue as many people doing type-level programming have variables named "kind". You ar right that problem would be much smaller if the keyword was "datakind" but somehow I am reluctant to seeing things like "datakindmember", "typeinstance", etc. What others think about this proposal? Janek --- Politechnika Łódzka Lodz University of Technology Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system.

3 3

RE: GHC 8.0.1 RC 1 and the -fwarn-monomorphism-restriction option
by Simon Peyton Jones 21 Jan '16

21 Jan '16

No, if that answers your question, good. Ben: is this change in the release notes? Simon | -----Original Message----- | From: andres.sicard.ramirez(a)gmail.com | [mailto:andres.sicard.ramirez@gmail.com] On Behalf Of Andrés Sicard- | Ramírez | Sent: 21 January 2016 13:25 | To: Simon Peyton Jones <simonpj(a)microsoft.com> | Cc: Thomas Miedema <thomasmiedema(a)gmail.com> | Subject: Re: GHC 8.0.1 RC 1 and the -fwarn-monomorphism-restriction | option | | On 21 January 2016 at 08:11, Simon Peyton Jones | <simonpj(a)microsoft.com> wrote: | > Can you give a small concrete test case, showing the different | behaviour? | | I received this answer from Thomas Miedema: | | Thomas Miedema <thomasmiedema(a)gmail.com> wrote: | > Reinstate monomorphism-restriction warnings | > | > This patch is driven by Trac #10935, and reinstates the | > -fwarn-monomorphism-restriction warning. It was first lost in | 2010: | > d2ce0f52d "Super-monster patch implementing the new typechecker | -- at | > last" | > | > I think the existing documentation is accurate; it is not even | > turned on by -Wall. | > | > I added one test. | | It was exactly what I was looking for. Do you still need a concrete | test case? | | -- | Andrés

2 2

GHC 8.0.1 RC 1 and the -fwarn-monomorphism-restriction option
by Andrés Sicard-Ramírez 21 Jan '16

21 Jan '16

Dear all, On 13 January 2016 at 10:43, Ben Gamari <ben(a)well-typed.com> wrote: > The GHC Team is very pleased to announce the first release candidate of > the Glasgow Haskell Compiler 8.0.1 release. For compiling Agda we use the -fwarn-monomorphism-restriction option. Using GHC 7.6.3, 7.8.4 and 7.10.3 we don't get any warning, but using GHC 8.0.1 RC 1 this option generates warnings in 103 files. Could someone give me some information about this new behaviour? Best, -- Andrés

1 0

Fwd: Host-Oriented Template Haskell
by Ericson, John 20 Jan '16

20 Jan '16

Cross-posting this as was suggested on the Haskell-Cafe list. While I envision this as normal feature that anyone can use, in practice its biggest consumers would be GHC devs. John ---------- Forwarded message ---------- From: Ericson, John <john_ericson(a)brown.edu> Date: Tue, Jan 19, 2016 at 1:17 PM Subject: Host-Oriented Template Haskell To: Haskell-Cafe <haskell-cafe(a)haskell.org> As is well known, TH and cross-compiling do not get along. There are various proposals on how to make this interaction less annoying, and I am not against them. But as I see it, the problem is largely inherent to the design of TH itself: since values can (usually) be lifted from compile-time to run-time, and normal definitions from upstream modules to downstream modules' TH, TH and normal code must "live in the same world". Now this restriction in turn bequeaths TH with much expressive power, and I wouldn't advocate getting rid of it. But many tasks do not need it, and in some cases, say in bootstrapping compilers[1] themselves, it is impossible to use TH because of it, even were all the current proposals implemented. For these reason, I propose a new TH variant which has much harsher phase separation. Normal definitions from upstream modules can not be used, lifting values is either not permitted or is allowed to fail (because of missing/incompatible definitions), and IO is defined to match the behavior of the host, not target, platform (in the cross compiling case). The only interaction between the two phases is that quoted syntax is resolved against the the run-time phase's definitions (just like today). Some of you may find this a shoddy substitute for defining a subset of Haskell which behaves identically on all platforms, and optionally constraining TH to it. But the big feature that my proposal offers and that one doesn't is to be able to independently specify compile-time dependencies for the host-oriented TH---this is analogous to the newish `Setup.hs` dependencies. That in turns leads to what I think is the "killer app" for Host-Oriented TH: exposing the various prepossessors we use (alex, happy, hsc2hs, even CPP) into libraries, and side-stepping any need for "executable dependencies" in Cabal. Note also that at least hsc2hs additionally requires host-IO---there may not even exist a C compiler on the target platform at all. Finally, forgive me if this has been brought up before. I've been thinking about this a while, and did a final pass over the GHC wiki to make sure it wasn't already proposed, but I could have missed something (this is also my first post to the list). John [1]: https://github.com/ghcjs/ghcjs/blob/master/lib/ghcjs-prim/GHCJS/Prim/Intern…

2 4

ghci and unfoldings?
by Conal Elliott 20 Jan '16

20 Jan '16

I'm developing a GHC plugin (using HERMIT), and I'd like to use ghci to speed up development. I'm able to do so, except that my plugin critically needs access to unfoldings, which appear to be unavailable in ghci. A little experimenting with ghc shows me that "-O" is the key, but "-O" is incompatible with "--interactive" (as in ghci). Is there any way to persuade ghci to make unfoldings available? Thanks, - Conal

5 11

Special treatment of family and role in the parser
by Jan Stolarek 20 Jan '16

20 Jan '16

Richard, I still don't fully understand special treatment of 'role' and 'family' in the parser I asked about recently on Skype. Say I have: foo :: role -> role foo role = role This results in parse error of type signature, regardless of enabling or disabling -XRoleAnnotations. Using `role` as a variable name (not type variable) is fine though. This is a consequence of explicitly listing 'role' lexeme in the varid production in the parser, but not in tyvarid production. But if I add 'role' to tyvarid production (or, even better, push it to special_id production used both by varid and tyvarid) everything works perfectly, I can use `role` both as variable and type variable name. Role annotations also work. The only downside is a small increase in number of shift/reduce conflicts. If I treat 'family' in the same way (ie. add it to tyvarid production) the increase in shift/reduce conflicts really becomes significant: from 37 to 129. Is this the only reason we don't do it? As you can guess this question is related to open kinds work: I need to add 'kind' lexeme to special_id to make sure it is accepted as a variable and type variable name. Janek --- Politechnika Łódzka Lodz University of Technology Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system.

3 2

Library tests failing
by Simon Peyton Jones 20 Jan '16

20 Jan '16

I’m getting this collection of failing tests, all of a sudden (below). What’s up? I’m pretty sure it’s not my modifications. The failures ae =====> random1283(normal) 1 of 1 [0, 0, 0] cd . && "/5playpen/simonpj/HEAD-4/inplace/test spaces/ghc-stage2" -o random1283 random1283.hs -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-warn-missed-specialisations -fno-ghci-history -package containers > random1283.comp.stderr 2>&1 Compile failed (status 256) errors were: [1 of 1] Compiling Main ( random1283.hs, random1283.o ) random1283.hs:4:1: error: Failed to load interface for ‘System.Random’ Use -v to see a list of the files searched for. and in STM =====> stm050(normal) 1 of 1 [0, 0, 0] cd . && "/5playpen/simonpj/HEAD-4/inplace/test spaces/ghc-stage2" -o stm050 stm050.hs -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-warn-missed-specialisations -fno-ghci-history -package stm > stm050.comp.stderr 2>&1 Compile failed (status 256) errors were: <command line>: cannot satisfy -package stm (use -v for more information) Simon Unexpected failures: ../../libraries/random/tests random1283 [exit code non-0] (normal) ../../libraries/random/tests rangeTest [exit code non-0] (normal) ../../libraries/stm/tests T2411 [exit code non-0] (normal) ../../libraries/stm/tests T3049 [exit code non-0] (normal) ../../libraries/stm/tests T4057 [exit code non-0] (normal) ../../libraries/stm/tests cloneTChan001 [exit code non-0] (normal) ../../libraries/stm/tests stm050 [exit code non-0] (normal) ../../libraries/stm/tests stm054 [exit code non-0] (normal) ../../libraries/stm/tests stm055 [exit code non-0] (normal) ../../libraries/stm/tests stm056 [exit code non-0] (threaded1) ../../libraries/stm/tests stm060 [exit code non-0] (normal) ../../libraries/stm/tests stm061 [exit code non-0] (normal) ../../libraries/stm/tests stm062 [exit code non-0] (normal) ../../libraries/stm/tests stm064 [exit code non-0] (normal) ../../libraries/stm/tests stm065 [exit code non-0] (normal)

1 0

Proposal: Longer Testing Cycle
by Harry . 20 Jan '16

20 Jan '16

"Glasgow Haskell Compiler 8.0.1, release candidate 1" was recently announced, with a caveat that "This release candidate in particular is known to suffer from a few significant issues which are being actively worked upon ... In the coming weeks we will continue to iterate on these issues. We will also look at Trac tickets marked with "highest" priority on the release status page." This leads me to wonder whether release management know what the words "release" and "candidate" mean! I would like to propose that the builds which are currently branded "release candidate" be rebranded as "beta", seeing as that is what they actually are. When the release manager has a build which s/he feels is ready for release, it should be published as a release candidate. If after a couple of weeks or so the same build is still considered suitable for release, it can be released as is, otherwise a new release candidate and testing period are required.

2 2

How to build profiled stage1?
by Ömer Sinan Ağacan 19 Jan '16

19 Jan '16

I'm trying to debug my stage1 compiler and as a last resort I'm trying to build stage1 compiler using `-prof -fprof-auto` to be able to do `+RTS -xc -RTS` during the stage2 build. I tried couple of things but they all failed in different ways. As far as I understand, both SRC_HC_OPTS and GhcStage1HcOpts are passed to system-wide installed ghc during the stage1 build and libraries. So I do one of these changes: SRC_HC_OPTS = -O -H64m -prof -fprof-auto GhcStage1HcOpts = -O0 -DDEBUG -prof -fprof-auto The second change I want to make is I want to pass `+RTS -xc -RTS` to ghc-stage1, for that I'm making this change: GhcLibHcOpts = -O -dcore-lint -prof -fprof-auto But, no matter what else I change, I can't get past this stage: "/usr/local/bin/ghc" -hisuf hi -osuf o -hcsuf hc -static -O -H64m -Wall -package-db libraries/bootstrapping.conf -this-package-key ghc-8.1 -hide-all-packages -i -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage1/build -icompiler/stage1/build/autogen -Icompiler/stage1/build -Icompiler/stage1/build/autogen -Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/stage1 -optP-include -optPcompiler/stage1/build/autogen/cabal_macros.h -package-id array-0.5.1.0-960bf9ae8875cc30355e086f8853a049 -package-id base-4.8.2.0-0d6d1084fbc041e1cded9228e80e264d -package-id binary-0.8.0.0 -package-id bytestring-0.10.6.0-9a873bcf33d6ce2fd2698ce69e2c1c66 -package-id containers-0.5.6.2-59326c33e30ec8f6afd574cbac625bbb -package-id directory-1.2.2.0-660a7a83a753ed85c8a374c15dae2b97 -package-id filepath-1.4.0.0-f97d1e4aebfd7a03be6980454fe31d6e -package-id ghc-boot-8.1 -package-id hoopl-3.10.2.1 -package-id hpc-0.6.0.3 -package-id process-1.2.3.0-a22328103774f0499a990653944cbf99 -package-id template-haskell-2.11.0.0 -package-id time-1.5.0.1-1b9a502bb07a3e6f4d6935fbf9db7181 -package-id transformers-0.5.0.0 -package-id unix-2.7.1.0-bb54ee8f9f6b2600aae7a748eb88a610 -Wall -fno-warn-name-shadowing -this-package-key ghc -XHaskell2010 -DSTAGE=1 -Rghc-timing -O0 -DDEBUG -prof -fprof-auto -no-user-package-db -rtsopts -odir compiler/stage1/build -hidir compiler/stage1/build -stubdir compiler/stage1/build -c compiler/utils/Exception.hs -o compiler/stage1/build/Exception.o compiler/utils/Exception.hs:10:1: Failed to load interface for ‘Control.Monad.IO.Class’ Perhaps you haven't installed the profiling libraries for package ‘transformers-0.5.0.0’? Use -v to see a list of the files searched for. <<ghc: 24684488 bytes, 15 GCs, 1388900/2559496 avg/max bytes residency (2 samples), 46M in use, 0.000 INIT (0.001 elapsed), 0.003 MUT (0.005 elapsed), 0.015 GC (0.019 elapsed) :ghc>> I tried enabling library-profiling in my global Cabal config, but that didn't help. Any ideas how to do this? If it matters, I'm on Linux. NOTE: If I pass -v to GHC, it lists this place in the list of locations searched: /home/omer/haskell/ghc_unboxed_sums/libraries/transformers/dist-boot/build/Control/Monad/IO/Class.p_hi Indeed, the file is not there. When I look at all the command the build system run at this point, I see lines like this: "/usr/local/bin/ghc-pkg" update --force --package-db=libraries/bootstrapping.conf libraries/transformers/dist-boot/inplace-pkg-config Reading package info from "libraries/transformers/dist-boot/inplace-pkg-config" ... done. transformers-0.5.0.0: Warning: Unrecognized field abi on line 47 transformers-0.5.0.0: Warning: haddock-interfaces: /home/omer/haskell/ghc_unboxed_sums/libraries/transformers/dist-boot/doc/html/transformers/transformers.haddock doesn't exist or isn't a file transformers-0.5.0.0: cannot find any of ["Control/Applicative/Backwards.hi","Control/Applicative/Backwards.p_hi","Control/Applicative/Backwards.dyn_hi"] (ignoring) transformers-0.5.0.0: cannot find any of ["Control/Applicative/Lift.hi","Control/Applicative/Lift.p_hi","Control/Applicative/Lift.dyn_hi"] (ignoring) transformers-0.5.0.0: cannot find any of ["Control/Monad/Signatures.hi","Control/Monad/Signatures.p_hi","Control/Monad/Signatures.dyn_hi"] (ignoring) transformers-0.5.0.0: cannot find any of ["Control/Monad/Trans/Class.hi","Control/Monad/Trans/Class.p_hi","Control/Monad/Trans/Class.dyn_hi"] (ignoring) transformers-0.5.0.0: cannot find any of ["Control/Monad/Trans/Cont.hi","Control/Monad/Trans/Cont.p_hi","Control/Monad/Trans/Cont.dyn_hi"] (ignoring) transformers-0.5.0.0: cannot find any of ["Control/Monad/Trans/Except.hi","Control/Monad/Trans/Except.p_hi","Control/Monad/Trans/Except.dyn_hi"] (ignoring) transformers-0.5.0.0: cannot find any of ["Control/Monad/Trans/Error.hi","Control/Monad/Trans/Error.p_hi","Control/Monad/Trans/Error.dyn_hi"] (ignoring) transformers-0.5.0.0: cannot find any of ["Control/Monad/Trans/Identity.hi","Control/Monad/Trans/Identity.p_hi","Control/Monad/Trans/Identity.dyn_hi"] (ignoring) Then, after a while it's building transformers in a different way, using arguments like `-dep-makefile` etc. which are as far as I can see not documented in the GHC man page. When I look libraries/transformers I only see a directory named "dist-boot" with some weird files with ".haskell" extensions. I'm quite confused about how this is supposed to work. Can any of the build system experts help me here? This wiki page https://ghc.haskell.org/trac/ghc/wiki/Debugging/Compiler#Addingdebuggingcod… says "if you have built a profiling compiler ..." but it doesn't say anything about how to actually build it. Thanks.

1 1

Fixing #11444 - OK-for-speculation check rejects valid program?
by Ömer Sinan Ağacan 19 Jan '16

19 Jan '16

I found one of the problems with #11444, but I don't know how to fix it. The problem is that the desugarer is generating this function: ptrEq [InlPrag=NOINLINE] :: forall a_a1wc. a_a1wc -> a_a1wc -> Bool [LclIdX, Str=DmdType] ptrEq = \ (@ a_a1Ts) (x_a1we :: a_a1Ts) (y_a1wf :: a_a1Ts) -> case x_a1we of x_X1wq { __DEFAULT -> case y_a1wf of y_X1ws { __DEFAULT -> == @ Int GHC.Classes.$fEqInt (case reallyUnsafePtrEquality# @ a_a1Ts x_X1wq y_X1ws of wild_00 { __DEFAULT -> GHC.Types.I# wild_00 }) (GHC.Types.I# 1#) } } Which is lint-safe. Then, the optimizer is transforming this into: ptrEq [InlPrag=NOINLINE] :: forall a_a1wc. a_a1wc -> a_a1wc -> Bool [LclIdX, Arity=2, Str=DmdType, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [20 20] 71 0}] ptrEq = \ (@ a_a1Ts) (x_a1we :: a_a1Ts) (y_a1wf :: a_a1Ts) -> case x_a1we of x_X1wq { __DEFAULT -> case y_a1wf of y_X1ws { __DEFAULT -> eqInt (I# (reallyUnsafePtrEquality# @ a_a1Ts x_X1wq y_X1ws)) (I# 1#) } } The problem with this, according to the linter, is the argument of I# is not OK-for-speculation (the expression `reallyUnsafePtrEquality# @ a_a1Ts x_X1wq y_X1ws`). The reason is because arguments of `reallyUnsafePtrEquality#` are not OK-for-speculation, because their types are polymorphic, and variables with polymorphic types are not OK for speculation. However, I think this expression should be OK-for-speculation, because it can't fail, the primop is not out-of-line etc. I think all the requirements for being OK for speculation hold here. So my questions are: - Does that look like a correct optimization transformation? (it looked OK to me, but wanted to make sure) - Am I right that this expression should be OK for speculation? - What's a good way to make this code lint-safe? Thanks..

1 0