- ghc-devs - Haskell.org

Why doesn’t the simple optimizer fuse casts?
by Alexis King 28 Apr '20

28 Apr '20

This question is spurred by curiosity more than anything else, but I’ve noticed that the simple optimizer doesn’t fuse nested casts, and I’m wondering if there’s any reason it couldn’t. To make what I’m talking about more concrete, suppose we have an expression like this: (x |> co) |> sym co It seems like it would be trivial for simpleOptExpr to fuse the nested casts to get x |> co; sym co and then the coercion optimizer could get rid of it entirely. Moreover, this seems within the spirit of the simple optimizer, since it’s really just “cleaning up” an expression. Is there any reason the simple optimizer doesn’t do this, or is it just something nobody implemented? (For context, I’ve recently been staring at a lot of -ddump-ds output, and there happen to be a bunch of nested casts in the result that are really just noise. It would be nice if the simple optimizer got rid of them for me.) Alexis

4 5

RE: T13456
by Simon Peyton Jones 28 Apr '20

28 Apr '20

Ben I'm still getting framework failures from the testsuite, as below. But now it's not just me: it's CI! See !2600 which is failing in this way. It'd be good to nail this... it seems wrong to have to ignore framework failures when checking that a build validates. Simon | -----Original Message----- | From: Simon Peyton Jones | Sent: 20 April 2020 21:42 | To: Ben Gamari <ben(a)well-typed.com> | Subject: RE: T13456 | | Thanks! | | | -----Original Message----- | | From: Ben Gamari <ben(a)well-typed.com> | | Sent: 20 April 2020 18:57 | | To: Simon Peyton Jones <simonpj(a)microsoft.com>; ghc-devs <ghc- | | devs(a)haskell.org> | | Subject: Re: T13456 | | | | Simon Peyton Jones via ghc-devs <ghc-devs(a)haskell.org> writes: | | | | > I'm getting this failure (below) from validate fairly consistently. | | > It is often silenced by adding an empty file | | > ghci/should_run/T13456.stderr But it's troubling. Does anyone else | see | | this? How can I debug it? | | > | | Indeed this is odd. I have not seen this in CI or my local builds. It's | | possible that I have seen it in local builds that were failing for | other | | reasons but ignored it. | | | | While I don't know why you are seeing these failures in general, the | fact | | that they are reported as framework failures is arguably a bug. I would | | argue that we should treat a non-existing .stderr file as we would an | | empty file. I've opened !3121 fixing this. Hopefully you will see a | more | | helpful error message with this patch. | | | | Cheers, | | | | - Ben

2 2

Desugaring matches with already-desugared RHSs?
by Alexis King 27 Apr '20

27 Apr '20

Hi all, I’m currently in the process of rewriting most of the arrow desugaring code. One of the most awkward parts of the current implementation is the way case commands are desugared. Given a case command like case e1 of A a b -> cmd1 B c -> cmd2 C d e f -> cmd3 the desugarer actually replaces each command on the RHS with an Either-wrapped tuple to get something like this: arr (\env -> case e1 of A a b -> Left (Left (a, b)) B c -> Left (Right c) C d e f -> Right (d, e, f)) >>> ((cmd1 ||| cmd2) ||| cmd3) This means the RHSs of the case expression are really already desugared, and ideally they would be CoreExprs, but matchWrapper expects the RHSs to be HsExprs. The current implementation accommodates this restriction by building fake HsExprs with no location information, but this means the logic for building the tuples in the RHSs has to be duplicated (since other places do want CoreExprs). I was thinking it would be nice to avoid this hack, but I’m not sure what the best way to do it is. One way would be to create a variant of matchWrapper with a type like matchWrapper' :: HsMatchContext GhcRn -> Maybe (LHsExpr GhcTc) -> MatchGroup GhcTc rhs -> (rhs -> DsM CoreExpr) -- how to desugar the RHSs -> DsM ([Id], CoreExpr) and update dsGRHSs to accept an extra argument as well. Then the arrow desugaring code could just pass `return` to matchWrapper' so it wouldn’t touch its RHSs. But I’m not sure if this approach makes sense — nothing else in the desugarer seems to work this way. Is there a better approach I’m not seeing? Thanks, Alexis

2 1

Spam projects on gitlab
by Sylvain Henry 26 Apr '20

26 Apr '20

Hi, I've just noticed these spam projects on our gitlab: - https://gitlab.haskell.org/craigonaldson/lumaslim - https://gitlab.haskell.org/AnthonyMussen/survey-of-evianne-cream - https://gitlab.haskell.org/RobertoHeard/robertoheard - https://gitlab.haskell.org/salihagenter/commission-based-business-in-india Can someone remove them? Thanks, Sylvain

2 1

Demand signature grammar
by Ben Gamari 24 Apr '20

24 Apr '20

Hello everyone, I routinely find myself having to dig through the Outputable instances in Demand.Types to decipher our joint demand signature syntax. Tonight I finally broke down and extracted a BNF-like grammar summarizing the syntax. It can be found on the Wiki [1]. I hope it is helpful for others as well. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/compiler/demand

2 1

Re: "Extensible interface files" work and ANN pragmas
by Matthew Pickering 23 Apr '20

23 Apr '20

Hi Josh, I don't think this addresses the points mine or Zubin's email that is it not correct to write a HIE file with a different BinHandle. If you do this then you will end up with a HIE file which contains Names which don't contain any SrcSpan information. If I am misunderstanding then please forgive me. Cheers, Matt On Thu, Apr 23, 2020 at 4:06 PM Josh Meredith <joshmeredith2008(a)gmail.com> wrote: > > Since the current HIE serialisation function writes to a BinHandle, which it initialises itself, the simple way to implement the HIE field would be to change the handle to an argument: > > writeHieFile :: FilePath -> HieFile -> IO () > writeHieFile hie_file_path hiefile = do > bh0 <- openBinMem initBinMemSize > -- Actual serialisation work > > becomes > > writeHieFile :: FilePath -> HieFile -> IO () > writeHieFile hie_file_path hiefile = do > bh0 <- openBinMem initBinMemSize > writeHie hiefile bh0 > > writeHie :: HieFile -> BinHandle -> IO () > writeHie hiefile bh = do > -- Actual serialisation work > > Then the existing discrete file can continue to use writeHieFile, and the field can reuse the existing implementation via writeHie: > > writeIfaceFieldWith :: FieldName -> (BinHandle -> IO ()) -> ModIface -> IO ModIface > > writeHieField :: HieFile -> ModIface -> IO ModIface > writeHieField hiefile iface = writeIfaceFieldWith "ghc/hie" (writeHie hiefile) iface > > I hope this clarifies how I intend these more edge cases to work? > > Cheers, > Josh > > > On Thu, 23 Apr 2020 at 20:25, Zubin Duggal <zubin.duggal(a)gmail.com> wrote: >> >> Yes, Matthew is correct, the symbol table for Names used by HIE files is >> quite distinct from the usual Iface symbol table for Names. Sharing the HIE >> symbol table and the Iface symbol table for names will be quite tricky. >> >> One crucial difference is that we also save information about local names >> to the symbol table for HIE files. >> >> Here is how names are stored in the HIE symbol table: >> >> data HieName >> = ExternalName !Module !OccName !SrcSpan >> | LocalName !OccName !SrcSpan >> | KnownKeyName !Unique >> >> And the usual symbol table(KnownKeyNames are implicitly handled as a separate case): >> >> type OnDiskName = (UnitId, ModuleName, OccName) >> >> So the merge of HIE and HI files will have to be careful about preserving these >> semantics. For instance, the `Binary` instances for HIE file data structures use >> putName_, which will have the wrong semantics after this merge. We could possibly >> get around this by having ExtensibleFields be allowed to override the UserData >> field of the BinHandle. >> >> Thanks to Matthew for bringing this up this important point. >> >> - Zubin >> >> On 20/04/23 09:06, Matthew Pickering wrote: >> > I also looked at this patch briefly now and it's my understanding that >> > the intention is to use this for HIE files as well? >> > >> > HIE files currently serialises Names differently to normal interface >> > files (to also include the SrcSpan) and it wasn't clear to me that the >> > current implementation would allow for this. >> > >> > Zubin/Josh could you please comment? >> > >> > Otherwise looks like a nice patch. >> > >> > Cheers, >> > >> > Matt >> > >> > On Thu, Apr 23, 2020 at 8:57 AM Ömer Sinan Ağacan <omeragacan(a)gmail.com> wrote: >> > > >> > > The "extensible interface files" [1, 2] work has been discussed at GHC calls a >> > > few times and the conclusion was we were going to document why current >> > > annotation mechanism (ANN pragmas) are insufficient and we need yet another way >> > > to put stuff into interfaces. >> > > >> > > Unfortunately the MR was merged before that's done and so it's currently >> > > undocumented and it's still unclear what's insufficient about ANN pragmas or how >> > > the new mechanism differs. >> > > >> > > I'm currently working on an interface files related patch (#16885) so I have to >> > > maintain both of these features now. It'd be good to know why both is necessary. >> > > If ANN is no longer useful or needed could we deprecate it in favor of the new >> > > mechanism and remove it in a few releases? That's help maintaining the code in >> > > the future. >> > > >> > > Could people involved in this design and patch please document the thought >> > > process here? >> > > >> > > Thanks, >> > > >> > > Ömer >> > > >> > > [1]: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/2948 >> > > [2]: https://gitlab.haskell.org/ghc/ghc/-/wikis/Extensible-Interface-Files >> > > _______________________________________________ >> > > ghc-devs mailing list >> > > ghc-devs(a)haskell.org >> > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

1 0

Recompilation avoidance questions
by Ömer Sinan Ağacan 23 Apr '20

23 Apr '20

Hi all, I'm currently reading the "recompilation avoidance" wiki page [1], and I have a few questions about the current design. The wiki page says (in the paragraph "Suppose the change to D ...") if a module B re-exports x from module D, changing x in D does not cause any changes in B's interface. I'm wondering why this is the case. To me this doesn't make sense. Anything that can potentially effect users of B should be a part of B's interface. This includes re-exports. I don't understand why there is a difference between normal exports and re-exports. As far as users of the module concerned there's no difference. So I'd expect any changes in re-exports to make a difference in B's interface. The wiki page says (in "Why not do (1)", where (1) refers to making D.x part of B's interface) that this is because sometimes changes in D.x should not cause recompiling B's users. I don't understand why (1) would cause this problem. If we make x a part of B, as if it's defined in B, similar to how we can avoid recompilation of users of B when a definition of B changes but the interface is the same, we could avoid recompiling users when D.x changes. For example, -- B.hs module B where b = 123123 -- Main.hs import B main = print b $ ghc-stage1 Main.hs [1 of 2] Compiling B ( B.hs, B.o ) [2 of 2] Compiling Main ( Main.hs, Main.o ) Linking Main ... Now if I update B and recompile I'll only link Main, won't recompile it: -- B.hs module B where b = 123123 + 12308 $ ghc-stage1 Main.hs [1 of 2] Compiling B ( B.hs, B.o ) Linking Main ... Now suppose B.b was a re-export from D. I don't understand why changing it in D would cause recompiling Main if we make b a part of B's interface. I think what would happen is: because D's interface hash won't change we won't recompile B. No problems at all. Finally, I'm a bit confused about this part > To ensure that A is recompiled, we therefore have two options: > ... > (2) arrange to touch B.hi and C.hi even if they haven't changed. I don't understand how touching is relevant, as far as I understand touching can't force recompilation. Example: $ ghc-stage1 Main.hs [1 of 3] Compiling A ( A.hs, A.o ) [2 of 3] Compiling B ( B.hs, B.o ) [3 of 3] Compiling Main ( Main.hs, Main.o ) Linking Main ... $ touch A.hi $ ghc-stage1 Main.hs $ touch B.hi $ ghc-stage1 Main.hs Am I missing anything? Thanks, Ömer [1]: https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/compiler/recompilatio…

2 3

"Extensible interface files" work and ANN pragmas
by Ömer Sinan Ağacan 23 Apr '20

23 Apr '20

The "extensible interface files" [1, 2] work has been discussed at GHC calls a few times and the conclusion was we were going to document why current annotation mechanism (ANN pragmas) are insufficient and we need yet another way to put stuff into interfaces. Unfortunately the MR was merged before that's done and so it's currently undocumented and it's still unclear what's insufficient about ANN pragmas or how the new mechanism differs. I'm currently working on an interface files related patch (#16885) so I have to maintain both of these features now. It'd be good to know why both is necessary. If ANN is no longer useful or needed could we deprecate it in favor of the new mechanism and remove it in a few releases? That's help maintaining the code in the future. Could people involved in this design and patch please document the thought process here? Thanks, Ömer [1]: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/2948 [2]: https://gitlab.haskell.org/ghc/ghc/-/wikis/Extensible-Interface-Files

3 2

GHC documentation outdated
by Wolfgang Jeltsch 20 Apr '20

20 Apr '20

Hi! the URL https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/index.html seems to still point to the GHC 8.8.3 documentation. All the best, Wolfgang

3 3

T13456
by Simon Peyton Jones 20 Apr '20

20 Apr '20

I'm getting this failure (below) from validate fairly consistently. It is often silenced by adding an empty file ghci/should_run/T13456.stderr But it's troubling. Does anyone else see this? How can I debug it? Thanks Simon Framework failures: /tmp/ghctest-31oxzmog/test spaces/ghci/should_run/T13456.run T13456 [Traceback (most recent call last): File "/home/simonpj/code/HEAD-1/testsuite/driver/testlib.py", line 996, in test_common_work do_test(name, way, func, args, files) File "/home/simonpj/code/HEAD-1/testsuite/driver/testlib.py", line 1094, in do_test result = func(*[name,way] + args) File "/home/simonpj/code/HEAD-1/testsuite/driver/testlib.py", line 1213, in ghci_script return simple_run( name, way, cmd, getTestOpts().extra_run_opts ) File "/home/simonpj/code/HEAD-1/testsuite/driver/testlib.py", line 1638, in simple_run stderr=read_stderr(name), File "/home/simonpj/code/HEAD-1/testsuite/driver/testlib.py", line 1808, in read_stderr return in_testdir(name, 'run.stderr').read_text(encoding='UTF-8') File "/usr/lib/python3.6/pathlib.py", line 1196, in read_text with self.open(mode='r', encoding=encoding, errors=errors) as f: File "/usr/lib/python3.6/pathlib.py", line 1183, in open opener=self._opener) File "/usr/lib/python3.6/pathlib.py", line 1037, in _opener return self._accessor.open(self, flags, mode) File "/usr/lib/python3.6/pathlib.py", line 387, in wrapped return strfunc(str(pathobj), *args) FileNotFoundError: [Errno 2] No such file or directory: '/tmp/ghctest-31oxzmog/test spaces/ghci/should_run/T13456.run/T13456.run.stderr' ] (ghci)

2 1