August 2019 - ghc-devs

Contributing to GHC : Newbie
by Avneesh Chadha 20 Aug '19

20 Aug '19

Hi, I am trying to contribute to GHC and am a complete newbie at this. The new contribution guide pointed me to the issues page(I was able to build the GHC from the code), and I was able to find this <https://gitlab.haskell.org/ghc/ghc/issues/16766> feature request. However it does not have any information apart from the feature information. Could someone please add more information to the issue? Warm Regards, Avneesh Chadha Phone:+917838478116 GitHub <https://github.com/avneesh91>|LinkedIn <https://www.linkedin.com/in/avneesh-chadha-0bb6b7aa/>|Blog <https://technokeeda.com/> PS: I am sorry for spamming everyone in-case this is not the correct forum , I would appreciate if someone could point to the right one.

2 1

Haskell implementors workshop
by Simon Peyton Jones 20 Aug '19

20 Aug '19

Colleagues At the Haskell Implementors Workshop on Friday there is a 23-min slot for an update on GHC status. It's followed by panel discussion. In our annual status reports I have typically summarised what is going on with a few slides. But as GHC grows, and more people contribute, it gets harder to do a good job of making such a summary. So this year I plan to: 1. Summarise some highlights that I know about 2. Invite anyone in the room who would like to briefly describe what they are working on - or have proudly completed in the last year - to grab the microphone and tell everyone about it. 3. Ben will summarise progress on CI, Gitlab, and Hadrian 4. Joachim will say what's happened on the GHC-proposal front To make (2) work * Come to the front so that each handover takes only a few seconds. * Be enthusiastic but brief. Thirty seconds, not two minutes. We only have 25 mins for the whole thing. * If you aren't at ICFP, but would have liked to describe your project to the audience, do send me a couple of sentences that I can use on your behalf. * It's a GHC status session, so anything in the GHC ecosystem is fair game, including different back ends, IDE work, plugins, etc. Tell me in advance if you like, but it's also fine just to be ready on the day. Thanks! Simon

1 0

Properly writing typechecker plugins
by Alexis King 17 Aug '19

17 Aug '19

Hi all, I have recently decided to try writing a GHC typechecker plugin so I can get my hands on some extra operations on type-level strings. My plugin works, but only sort of—I know some things about it are plain wrong, and I have a sneaking suspicion that plenty of other things are not handled properly. First, some context about what I do and don’t already know: I have a high-level understanding of the basic concepts behind GHC’s solver. I understand what evidence is and what purpose it serves, I mostly understand the different flavors of constraints, and I think I have a decent grasp on some of the operational details of how individual passes work. I’ve spent a little time reading through comments in the GHC source code, along with pieces of the source code itself, but I’m sure my understanding is pretty patchy. With that out of the way, here are my questions: First, I’m trying to understand: why are wanted constraints passed to typechecker plugins unflattened? This is my single biggest point of confusion. It certainly seems like the opposite of what I want. Consider that I have a type family type family ToUpper (s :: Symbol) :: Symbol where {} that I wish to solve in my plugin. At first, I just naïvely looked through the bag of wanted constraints and looked for constraints of the shape t ~ ToUpper s but this isn’t good enough, since my plugin regularly receives constraints that look more like t ~ SomeOtherTypeFamily (ToUpper s) so I have to recursively grovel through every type equality constraint looking for an application of a family I care about. Furthermore, once I’ve found one, I’m not sure how to actually let GHC know that I’ve solved it—do I really have to just generate a new given constraint and let GHC’s solver connect the dots? I have seen the note on the typechecker plugins wiki page <https://gitlab.haskell.org/ghc/ghc/wikis/plugins/type-checker#under-discuss…> about possibly baking support for type families into the plugin interface, which would indeed be nicer than the status quo, but it seems odd to me that they aren’t just passed to plugins flattened, which seems like it would spare a lot of effort. Isn’t the flattened representation really what typechecker plugins would like to see, anyway? But let’s put families aside for a moment. I’m not just solving type families in my plugin, I’m also solving classes. These classes have no methods, but they do have functional dependencies. For example, I have a class class Append (a :: Symbol) (b :: Symbol) (c :: Symbol) | a b -> c, a c -> b, b c -> a which is like GHC.TypeLits.AppendSymbol, but the fundeps make GHC a bit happier when running it “backwards” (since GHC doesn’t really know about AppendSymbol’s magical injectivity, so it sometimes complains). In any case, I was hoping that GHC’s solver would handle the improvement afforded by the fundeps for me once I provided evidence for Append constraints, but that doesn’t seem to be the case. Currently, I am therefore manually generating derived constraints based on the functional dependency information, plumbing FunDepOrigin2 through and all. Is there some way to cooperate better with GHC’s solver so I don’t have to duplicate all that logic in my plugin? I guess one thing I didn’t try is returning given constraints from my solver instead of just solving them and providing evidence. That is, if my plugin received a [W] d1 :: Append "foo" "bar" c constraint, then instead of solving the constraint directly, I could leave it alone and instead return a new constraint [G] d2 :: Append "foo" "bar" "baz" and presumably GHC’s solver would use that constraint to improve and solve d1. But similar to my confusion about type families above, I’m uncertain if that’s the intended method or not, since it seems like it’s sort of circumventing the plugin API. Finally, on a related note, building evidence for these solver-generated typeclass instances is a bit of a pain. They have no methods, but they do sometimes have superclasses. Currently, I’ve been generating CoreExprs as carefully as I’m able to after reading through the desugaring code: I call dataConWrapId on the result of classDataCon, then use mkTyConApp and mkCoreApps on that directly. It seems to work okay now, but it didn’t always: -dcore-lint thankfully caught my mistakes, but I’ve been wondering if there’s a safer way to build the dictionary that I’ve been missing. That’s it for now—I’ve just been muddling through until things work. Once I get something that feels closer to right, maybe I’ll put the code somewhere and ask for more low-level comments if anyone would like to take the time to offer them, but for now, I’m still working on the high-level ideas. The wiki pages I’ve found have been very helpful; my appreciation to all who have contributed to them! Many thanks, Alexis

2 4

ANN: IOHK is looking for Functional Compiler Engineers
by Manuel M T Chakravarty 13 Aug '19

13 Aug '19

The IOHK Plutus Team, which works on a Haskell-based platform for contracts on the Cardano blockchain, is looking for new team members: https://iohk.io/careers/#op-341518-functional-compiler-engineer See also Phil Wadler’s blog post: http://wadler.blogspot.com/2019/08/iohk-is-hiring.html A core component of the Plutus Platform is a GHC plugin that translates GHC Core to the on-chain Plutus Core language. A central part of the underlying transformation scheme is described in https://iohk.io/research/library/#unraveling-recursion-compiling-an-ir-with… Manuel

1 0

margebot.
by Phyx 13 Aug '19

13 Aug '19

Hello, margebot seems down, or did I miss a memo on how to commit now? Cheers, Tamar

1 0

Gitlab's disk full again
by Ömer Sinan Ağacan 12 Aug '19

12 Aug '19

Hi, Just yesterday Gitlab was giving 500 because the disk was full. Ben deleted some files, but in less than 24h it's full again. This started happening regularly, I wonder if we could do something about this. The reason this time seems to be that Gitlab started generating 22G-large backups daily since the 7th. I'm not sure how important those backups are so I'm not deleting them. There's also a large docker-registry directory (101G). I think it might be good to set up some kind of downtime monitoring or maybe something on the Gitlab server to send an email when the disk is nearly full. It could send an email to people who has access to the server. It'd also be good to come up with an action plan when this happens. I have access to the server, but I have no idea which files are important. Documenting Gitlab setup (and the server details) in more details might be helpful. Does anyone have any other ideas to keep the server running? Ömer

3 3

PseudoOps in primops.txt.pp
by Sebastian Graf 11 Aug '19

11 Aug '19

Hey fellow devs, While implementing new PseudoOps, a couple of questions popped up: 1. What are PseudoOps? When do we want to declare one? There doesn't seem to be any documentation around them. I only figured out that I probably want a PseudoOp by comparing to PrimOps I thought would be lowered at a similar stage (i.e. somewhere in Core or STG). 2. Why aren't GHC.Magic.{lazy,noinline,oneShot} PseudoOps? 3. Since we have to set all the IdInfo for `seq` and `noinline` manually, why is this incomplete? I.e., I'd expect a useful strictness signature and arity for both of these. Thanks! Sebastian

1 1

LoadAllTargets not loading dependencies
by Sam Halliday 08 Aug '19

08 Aug '19

Hello all, I've been following along with Stephen Diehl's blog series on the ghc api and I am using `load LoadAllTargets` on a .hs file (let's call it Wibble.hs) and then typechecking. All seems well until I add a second module (let's call it Wobble.hs) in the same package and import it from Wibble. I can see that the load has correctly calculated the dependency graph and includes Wobble in the dependencies of Wibble. But if I try to typecheck Wibble, then I get an error: Could not find module ‘Wobble’ Use -v to see a list of the files searched for. | 4 | import Wobble | ^^^^^^^^^^^^^^^^^^^^^^^ I have separately compiled the package, and can see its packagedb is listed in the .ghc.env file. What else do I need to do so that Wibble can see Wobble? -- Best regards, Sam

2 2

ModuleInfo.minf_rdr_env not exposed
by Sam Halliday 08 Aug '19

08 Aug '19

Hi all, Is there a reason why minf_rdr_env (a field in ModuleInfo) is not exposed? It's possible to reconstruct it in 8.4.4 (the only version I'm looking at) with a TypecheckedModule via let (tc_gbl_env, _) = GHC.tm_internals_ tmod minf_rdr_env = tcg_rdr_env tc_gbl_env It's a useful thing to have for editor tooling (e.g. to get the correct qualified imported symbols that may be autocompleted). -- Best regards, Sam

2 3

Conveniently searching GitLab
by Ben Gamari 07 Aug '19

07 Aug '19

Hello everyone, I've long found GitLab's search interface to be rather clunky. Several of the issues I've noted have been reported upstream but progress in resolving them seems to be slow. Consequently, I have implemented a workaround [1] which addresses most of my typical use-cases. This is essentially a thin wrapper around GitLab's various search facilities which intelligently routes requests according to a simple (and hopefully intuitive) query syntax. For instance, to * navigate to GHC issue #123: search for `#123` * search for GHC issues related to unboxed tuples: search for `# unboxed tuples` * navigate to the `ghc/head.hackage` project: search for `ghc/head.hackage>` * navigate to merge request !3 of the `ghc/head.hackage` project: search for `ghc/head.hackage!3` * navigate to commit e130fb57f7991575d848612abafe9ad10129131c of the `ghc/ghc` project: search for `ghc/ghc@e130fb57f7991575d848612abafe9ad10129131c` * search for merge requests of `haskell/ghcup` pertaining to Darwin: search for `haskell/ghcup! Darwin` Note that, as seen in the first two examples, the project name defaults to `ghc/ghc` if omitted. This interface is best used via your browser's search keywords feature [2]. To add a search keyword in Firefox you can right click on the search query input field and select "Add search keyword". To my surprise I didn't find a similarly convenient shortcut in Chromium. If you can think of any way in which the service can be improved, feel free to open a pull request against the upstream repository [3]. Cheers, - Ben [1] https://search.gitlab.haskell.org/ [2] http://kb.mozillazine.org/Using_keyword_searches [3] https://gitlab.haskell.org/bgamari/gitlab-search-service

2 2