January 2016 - ghc-devs

Birthday greetings
by Simon Peyton Jones 20 Jan '16

20 Jan '16

Dear GHC devs (all 600+ of you), It’s my birthday (well it was a few minutes ago, but I became distracted by #11379). I am 58. GHC is alive and well and, happily, so am I. However, of late I have found that my GHC inbox, which I used to be able to keep under control, just grows and grows. Mostly this is good; it reflects the fact that GHC has lots of users, that they vigorously expand up to (and often well beyond) the limits of what GHC can do, and that increasingly GHC a lot of developers contributing actively to its code base. But it has its downsides. I used to be able to keep up with the Trac and email traffic. Trusty techniques like “delete anything mentioning ‘dynamic linking’ or ‘Unicode’” would cut the traffic in half. But that doesn’t work any more. Too many interesting things are happening. So this email is to say three things: · First, thank you to the increasingly large number of you who are contributing actively to GHC’s development. GHC is a big system, and no one person can be on top of all of it. GHC no longer depends on one of two people: it depends on all of you. You know who you are – thank you. · Second, apologies to anyone who is stuck waiting for me. Although there are large chunks of GHC that I know little about, there are other parts that are dear to my heart: the renamer, typechecker, Core, optimisation, and so on. I write code most days and enjoy it. So I do want to continue to play a very active supporting and reviewing role, as well as authoring, in these parts. But I’m conscious that doing so puts me in a lot of critical paths. Here’s a suggestion: if you are blocked on something from me, email me directly. By all means copy ghc-devs if you want others in the conversation, but make it clear that you need my input. That’ll work better than putting up a Phab review, or a Trac comment, and hoping I’ll see it. I probably will, but it won’t stick out from other 20 Phab reviews that I would like to do. I don’t promise to turn everything around fast, but it’ll increase the chances! · Third, in a vain attempt to at least keep some kind of handle on the state of play, I keep an ill-organised page of tickets that I’m interested in<https://ghc.haskell.org/trac/ghc/wiki/Status/SLPJ-Tickets>. A cursory glance will confirm that there is zero chance that I will attend to them all. So please do pick up some of them and dig in. Not many are trivial; most require some investigation, some design work, some discussion of alternatives, etc. But most of them would benefit from love and attention. If you are looking for suggestions for things to do, that might be a good place to start. Thanks! Simon

6 5

Serialized module
by Simon Marlow 20 Jan '16

20 Jan '16

As part of the recent Remote GHCi changes, I moved the module Serialized from the ghc package to ghc-boot. This is because it is shared by the ghci package and ghc itself. The only way to arrange that it was available to both ghc in stage1 and the ghci package (which is not a dependency of the stage1 ghc), was to put it in ghc-boot. Unfortunately this introduces some breakage because some external code import Serialized. I just ran across hint which fails to compile. I can fix this by re-introducing a Serialized module that re-exports module GHC.Serialized. But is that the right thing to do? Serialized is also re-exported by GhcPlugins. Should we be asking people to import that instead? Cheers, Simon

1 0

Re: equality relations: user-facing pretty-printing question
by Ryan Scott 19 Jan '16

19 Jan '16

In my ideal world, GHC would remember as much as what the user wrote as possible in printing error messages. So if the user writes: f :: Int ~ Char => ... Then GHC would remember that the context was written with a single tilde, and print out Int ~ Char in the error message explicitly wherever the full type signature of f is printed. What it sounds like, though, is that deep in the guts of the type inferencer, there's a chance that single-tilde equality might turn into double-tilde or tilde-hash equality at some point. In those cases, printing out the particular brand of tilde might get confusing. In such cases, we might compromise and print out something neutral like "is equal to". I suppose this would always be the case if you didn't explicitly write a ~ b and had to infer it. I'm not sure about the technical details of this though, i.e., if GHC actually remembers a ~ b all the way through the typechecking/inferencing pipeline. Ryan S.

6 8

Phab failing to apply patches
by Jan Stolarek 19 Jan '16

19 Jan '16

It seems that Phab is once again failing to apply patches (eg. D1778, which built perfectly fine until latest update). Is anyone else experiencing this? 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.

4 11

equality relations: user-facing pretty-printing question
by Richard Eisenberg 19 Jan '16

19 Jan '16

Hi devs, I've recently made a design decision for GHC 8.0 that I may wish to revisit, and I'd love some feedback. GHC 7.x has but one user-visible type equality relation, ~. The constraint (ty1 ~ ty2) is well-kinded only when ty1 and ty2 have the same kinds. And the solver works in terms of this very same equality, so error messages simply talk about ~. GHC 8.0, on the other hand, has three equality relations that might potentially appear to users. It retains ~. But it also has ~~, which is heterogeneous type equality, meaning that (ty1 ~~ ty2) is well-kinded even when ty1 and ty2 have different kinds. And it has ~#, which is the unlifted equality used in the solver. It turns out that ~~ and ~ are just wrappers around ~#. Because of all of this, GHC sometimes ends up thinking about ~~ or ~# even when the user has said ~. (See the definition of ~ in Data.Type.Equality, for example.) And it naively would print ~# a bunch in error messages. So, I put a little pretty-printing magic in that prints ~, ~~, and ~# all as ~ in user-facing output, unless the user writes -fprint-equality-relations. This design decision has kept error messages pretty. But it will be awfully confusing when someone intentionally uses ~~ and sees ~ in their output. And there's nothing to suggest -fprint-equality-relations. These sorts "hide the scary plumbing!" decisions irk me to no end when I find them in my operating system. But now I've done the same thing in GHC... which is why I want to re-examine this. What do you think? Do you see a better way to handle this? Thanks! Richard

1 0

Multiple GHC sessions
by Alan & Kim Zimmerman 19 Jan '16

19 Jan '16

At the moment there are issues with having multiple GHC API sessions in a single executable, which boil down to GHC having global variables. A quick grep over the GHC sources shows the following instances compiler/ghci/Linker.hs:90:GLOBAL_VAR_M(v_PersistentLinkerState, ... compiler/ghci/Linker.hs:91:GLOBAL_VAR(v_InitLinkerDone, .... compiler/main/StaticFlags.hs:94:GLOBAL_VAR(v_opt_C, .... compiler/main/StaticFlags.hs:95:GLOBAL_VAR(v_opt_C_ready, .... compiler/main/DynFlags.hs:4453:GLOBAL_VAR(v_unsafeGlobalDynFlags,.... ghc/GHCi/UI.hs:149:GLOBAL_VAR(macros_ref,.... Of these the v_unsafeGlobalDynFlags can probably be ignored, as they are intended to be used in very specific, limited circumstances only. So, would it be possible to create a structure housing the remaining ones, and somehow make it possible to access these in some kind of session? Or preferably get rid of them, or move them into existing structures such as DynFlags. This is an exploratory email, more to get a handle on what has been done/considered already in this space. The issue does have a major impact on tooling developers though. Regards Alan

5 7

Plugin from ghci REPL?
by Conal Elliott 18 Jan '16

18 Jan '16

Is it possible to have GHC plugins get invoked from the ghci *REPL* (in addition to loaded source modules)? I'm doing some monomorphization-based transformation, and currently I write scads of trivial monomorphic specialization definitions like > sumt6 = sum :: Tree 6 Int -> Int I'd instead love to enter "let sumt6 = sum :: Tree 6 Int -> Int" or (better) just "sum :: Tree 6 Int -> Int" into the REPL and have my plugin run, without having to keep monkeying with a source file and reloading. As I understand it, an expression is turned into "let it = ...", so maybe the expression option would come for free with the ability to run plugins on in-REPL definitions. -- Conal

1 0

Trac internal error
by Edward Z. Yang 18 Jan '16

18 Jan '16

When I posted the (attached) POST request to newticket, I got the following error. It did correctly add the ticket to the database. I've elided the form token from this. Trac detected an internal error: AttributeError: 'NoneType' object has no attribute 'split' Here's the contents of the POST request (my guess is that I put something bad in the CC field): field_summary=Turn+on+SplitSections+by+default field_reporter=ezyang field_description=This+is+a+general+tracking+bug+for+what+is+blocking+us+from+turning+on+`SplitSections`+by+default,+implemented+in+#8405.+Fixing+this,+and+mandating+use+of+the+gold+linker,+will+help+solve+#11285+(split+objects+make+linking+slow),+and+will+make+ghc-split+unnecessary,+mooting+#9832. I+encountered+some+misinformation+while+talking+to+people+about+this+featur… So,+can+we+turn+on+this+feature+by+default?+Does+it+subsume+split-objs?+Does+it+work+on+all+the+tier-1+platforms?+It+would+be+nice+if+bgamari,+olsner+and+co+could+weigh+in+here.+Thanks! field_type=task field_priority=normal field_milestone=8.2.1 field_component=Build+System field_version=8.0.1-rc1 field_keywords field_cc=bgamari,+olsner field_os=Unknown/Multiple field_architecture=Unknown/Multiple field_failure=None/Unknown field_testcase field_blockedby field_blocking=#11285 field_related field_differential field_wikipage field_owner=<+default+> sfp_email sfph_mail submit=Create+ticket

1 0

Re: issues on Glasgow Haskell Compiler 8.0.1, release candidate 1
by George Colpitts 17 Jan '16

17 Jan '16

Hi Ben Yes this fixes the issue I found on the Mac. Although it seems there is a minor problem that I encountered: sudo make install ... /usr/bin/install -c -m 644 docs/users_guide/ghc.1 "/usr/local/share/man/man1" install: /usr/local/share/man/man1/ghc.1: No such file or directory make[1]: *** [install_man] Error 71 make: *** [install] Error 2 bash-3.2$ rm /usr/local/share/man/man1/ghc.1 Also, again minor, with either source or binary distribution I am seeing the following warnings: Warning: /var/folders/9b/rh4y2gy92hgdb6ktv4df1jv00000gn/T/pkgConf-data-ordlist-0.4.78235644401115438165.0: Unrecognized field abi on line 15 when doing cabal installs, e.g. cabal install data-ordlist I believe somebody else asked, do we intend to distribute llvm with 8.0.1. If so I will wait for the next release candidate to test llvm otherwise I will install llvm 3.7 and test llvm Thanks George On Fri, Jan 15, 2016 at 11:11 AM, Ben Gamari <ben(a)well-typed.com> wrote: > George Colpitts <george.colpitts(a)gmail.com> writes: > > > installs fine on mac but cabal install vector fails on primitive, looks > to > > me like gmp library is not provided > > > I have built a new OS X binary [1] which should be linked against the > in-tree libgmp, fixing this issue (which we've been tracking as Trac > #11423). > > I have also pushed a 32-bit Windows build. > > Perhaps those affected by this issue could try this distribution? > > Cheers, > > - Ben > > > [1] > http://downloads.haskell.org/~ghc/8.0.1-rc1/ghc-8.0.0b.20160111-x86_64-appl… > > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > >

2 1

Explanation of a core-lint warning (Bad getNth)
by Jan Bracker 16 Jan '16

16 Jan '16

Hi, I am using the type checker plugin interface and I am trying to produce some evidence for type class instances. During compilation of one of my examples I get this core-lint error: *** Core Lint errors : in result of Simplifier *** <no location info>: Warning: [RHS of ds_a6bY :: (Set '["thres" :-> Int], Set (Unit Reader))] Bad getNth: Nth:0 (Nth:2 (Sub (Sym (TFCo:R:Inv[]Readerfg[0] <'["thres" :-> Int]>_N <'[]>_N)) ; (Inv <Reader>_N <'["thres" :-> Int]>_N (Sym TFCo:R:Unit[]Reader[0]))_R ; Sub (TFCo:R:Inv[]Readerfg[0] <'["thres" :-> Int]>_N <Unit Reader>_N))) Split '["thres" :-> Int] '[] (Union '["thres" :-> Int] '[]) Split '["thres" :-> Int] (Unit Reader) (Union '["thres" :-> Int] (Unit Reader)) I suppose "getNth" refers to the constructor "EvTupleSel" from "EvTerm", "TcNthCo" from "TcCoercion" or to "NthCo" from "Coercion". But I never produce evidence of the shape "getNth". My evidence production code can be found at [1] and the only place where evidence of this shape can come from is my "evaluateType" function [2] that calls "normaliseType" from the GHC module "FamInstEnv". You can reproduce the error by checking out commit 144525886ec107af6f1283b26b19f8125c980aa4 from [3] and running "make effect-example" in the top directory of the repository (GHC 7.10 or better is required and a sandbox is automatically created). The core-lint error does not seem to have any negative consequences when ignored. The produced executable works fine. Can somebody explain why it appears and maybe how I can fix it? Thank you! Jan [1] https://github.com/jbracker/polymonad-plugin/blob/144525886ec107af6f1283b26… [2] https://github.com/jbracker/polymonad-plugin/blob/144525886ec107af6f1283b26… [3] https://github.com/jbracker/polymonad-plugin

4 12