- ghc-devs - Haskell.org

Re: Recover role of a type variable in source Haskell
by Ryan Scott 07 Apr '19

07 Apr '19

It depends on what you mean by "source Haskell". If you're willing to consider including Template Haskell in your definition of "source", then the answer is yes, since there is a reifyRoles function [1] which gives you this information. I'm not aware of another way to accomplish this (without resorting to something like the GHC API). Ryan S. ----- [1] https://hackage.haskell.org/package/template-haskell-2.14.0.0/docs/Language…

1 0

Recover role of a type variable in source Haskell
by chessai . 07 Apr '19

07 Apr '19

Hi devs, Is it possible to programmatically recover the role of a type variable? Or, possibly, a list of the roles of the type variables from left to right? For example, if i have: data Foo a = Foo (1) newtype Bar a b = Bar (a -> b) (1) Getting the role list of (1) would give me [Phantom], and (2) would give me [Representational, Representational]. I know in compiler/types/TyCon.hs that TyCon has a list of Roles in it, but there doesn't seem to be any machinery available to do this in source haskell. Thanks

2 1

Re: Debug printing inside the typechecker knot
by Ryan Scott 05 Apr '19

05 Apr '19

> Did you mean "What is the TcHsSyn counterpart to TcMType.zonkTcTyVar"? D'oh. Yes, I did. > But it's never a bad idea to document more. I've documented all the wisdom from here in this wiki page [1]! Feel free to edit it if there are any corrections to be made. Ryan S. ----- [1] https://gitlab.haskell.org/ghc/ghc/wikis/commentary/compiler/tying-the-knot…

1 0

Can Gitlab's "issue was closed by ..." mails be improved?
by Ömer Sinan Ağacan 05 Apr '19

05 Apr '19

Hi, Currently Gitlab doesn't give any details of why an issue was closed, it just says "Issue was closed by ...". You have to go to the issue page to see that it was closed because of a closing merge request was merged. I'm wondering if this could be improved so that in the email it says "issue was closed by ... via commit ..." or something like that. Anyone know if there's already a ticket for this in Gitlab issue tracker? Ömer

1 0

Defining a wired-in type of a different kind
by Jan van Brügge 05 Apr '19

05 Apr '19

Hi, when trying to get familiar with the GHC code base for my Bachelor's thesis. I followed the GHC Wiki, especially the case study about the bool type. Now I wanted to add a new kind and a new type inhabiting this kind (without having to expose a data constructor, so without datatype promotion). So in TysWiredIn.hs I added the new TyCons and added them to the list of wired-in types: -- data Row a b rowKindCon :: TyCon rowKindCon = pcTyCon rowKindConName Nothing [alphaTyVar, betaTyVar] [] rowKind :: Kind rowKind = mkTyConTy rowKindCon -- data RNil :: Row a b rnilTyCon :: TyCon rnilTyCon = mkAlgTyCon rnilTyConName [] rowKind [] Nothing [] (mkDataTyConRhs []) (VanillaAlgTyCon (mkPrelTyConRepName rnilTyConName)) False rnilTy :: Type rnilTy = mkTyConTy rnilTyCon I also added two new empty data decls to ghc-prim, but if I inspect the kind of RNil it is not Row, but Type. So I think I am either understanding res_kind wrong or I have to do something completely different. I am also not sure how to verify that the code in TysWiredIn.hs is working at all, from all what I can tell it could just be the declarations in ghc-prim that result in what I see in ghci. Thank you and sorry for my beginner question Jan

5 6

Introducing bugs that are caught by slow validate?
by Ömer Sinan Ağacan 04 Apr '19

04 Apr '19

Hi all, I just run slow validate and it actually catches bugs (#16529) and some configuration problems in the test definitions (#!700). These are not caught by the CI jobs because they run normal validate instead of slow. (Actually they don't even run the validate script, but they run "test" instead of "slowtest", which I think is the main difference between normal validate and slow validate) As far as I can see we have nightly job definitions in .gitlab-ci.yml, which do slow validate, but I'm not sure if those are used? Would it be possible to switch over to slow validate in CI jobs? If slow validate takes too long on the CI servers, could we maybe configure CI tasks so that if the MR submitter is Marge, we run slow validate, otherwise we run fast validate? The problem with nightly jobs (assuming they're used) is that it's too late by the time they catch a test failure because the commits are already in the tree, and because nothing's blocked the bugs are more likely to stay unfixed. Ömer

3 2

Re: Debug printing inside the typechecker knot
by Ryan Scott 04 Apr '19

04 Apr '19

Good to know, thanks. I assume that TcMType.zonkTcTypes is to TcHsType.zonkTcTypeToTypes as TcMType.zonkTcTyVars is to TcHsType.zonkTyBndrs? Also, what exactly is the optimization that ZonkEnv performs in types? And why don't the functions in TcMType make use of this optimization? Ryan S.

2 3

Debug printing inside the typechecker knot
by Ryan Scott 04 Apr '19

04 Apr '19

I've recently found myself wanting to add some pprTrace statements in typechecker-related code but unable to do so, as the code would pull on knot-tied TyCons (leading to an infinite loop if actually ran). In particular, I want to print some code [1] in TcTyClsDecls.tcConDecl: ; (ze, tkvs) <- zonkTyBndrs tkvs ; (ze, user_tvs) <- zonkTyBndrsX ze user_tvs ; arg_tys <- zonkTcTypesToTypesX ze arg_tys ; ctxt <- zonkTcTypesToTypesX ze ctxt ; res_ty <- zonkTcTypeToTypeX ze res_ty ; let (univ_tvs, ex_tvs, tkvs', user_tvs', eq_preds, arg_subst) = rejigConRes tmpl_bndrs res_tmpl tkvs user_tvs res_ty In [2], goldfire claimed that there is a way to work around this problem now: > But you can do this. It just has to be before the final zonk. I see that rejigConRes is used after the final zonk. But there's nothing about that function that requires things be in their final state. The arguments need to be zonked, but they can be zonked by zonkTcType and friends, not zonkTcTypeToType and friends. So, for debugging: zonk everything with the functions in TcMType (not those in TcHsSyn). Then rejigConRes. Then print all the output you like. Then do the final zonk. This double-zonk is redundant, so it's not good to keep going forward, but it shouldn't cause other trouble. Unfortunately, this advice doesn't seem to pan out in practice. I started off by looking for a TcMType equivalent of this function: zonkTcTypeToTypeX :: ZonkEnv -> TcType -> TcM Type However, I am utterly unable to find anything defined in TcMType with a similar type signature. Actually, it's worse than that: there isn't a single mention of ZonkEnv anywhere in TcMType! So as far as I can tell, this advice is completely unimplementable, unless I'm missing something obvious. Any tips? Ryan S. ----- [1] https://gitlab.haskell.org/ghc/ghc/blob/51fd357119b357c52e990ccce9059c423cc… [2] https://phabricator.haskell.org/D4974#137224

2 1

In-tree invocation of GHC built with Hadrian
by Simon Peyton Jones 04 Apr '19

04 Apr '19

How can I run the inplace binary built by Hadrian. I tried this ~/code/HEAD/_build/stage0/bin/ghc -c Foo.hs but I got this ~/code/HEAD/_build/stage0/bin/ghc -c Foo.hs Foo.hs:1:8: error: Bad interface file: /opt/ghc/8.6.4/lib/ghc-8.6.4/base-4.12.0.0/Prelude.hi mismatched interface file versions (wanted "80920190403", got "8064") | 1 | module Foo where | ^^^ simonpj@MSRC-3645512:~/tmp$ Somehow the inplace binary built by Hadrian is looking for library files in completely the wrong place. What should I do? Simon

3 5

RE: Help with cabal
by Simon Peyton Jones 04 Apr '19

04 Apr '19

Ah, so you installed the `cabal-install-3.0` package? Yes I attached your repo and then said apt install cabal-install and lo! cabal 3.0 appeared in /opt/cabal/bin I did this because the vanilla Ubuntu distro only had cabal 1.24. And I could not update by saying “cabal install cabal-install” because cabal 1.24 fell over with that “futex error”. In the meantime you can just keep using your current cabal 3.0 exe; does `cabal --version` currently have any noticeable startup latency for you on WSL? No, no noticeable startup latency. I’ll do the reinstall thing in a few hrs, after you’d done your update. Thanks! SImon From: Herbert Valerio Riedel <hvriedel(a)gmail.com> Sent: 04 April 2019 13:45 To: Simon Peyton Jones <simonpj(a)microsoft.com> Subject: Re: Help with cabal On Thu, Apr 4, 2019 at 2:25 PM Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: But how do I "recompile your cabal 3.0 executable with the new GHC"? The cabal-3.0 I have is (I believe) installed by apt install cabal-install and so I suppose if I "upgrade", the new 'cabal' binary will WSL'd, no? Ah, so you installed the `cabal-install-3.0` package? If so, yes, it *will* be updated to the WSL version.... in about one hour... because it turns out I forgot to push the 3.0 packages to the WSL ppa... and I've just triggered a new build of cabal 3.0 packages which will take about one hour to show up there... :-) In the meantime you can just keep using your current cabal 3.0 exe; does `cabal --version` currently have any noticeable startup latency for you on WSL?

2 1