- ghc-devs - Haskell.org

Can't initialise vendored submodule
by Arnaud Spiwack 18 Aug '24

18 Aug '24

Dear all, I'm currently unable to build GHC's master branch as some of the submodules (presumably used by Hadrian) are making git pretty unhappy (I've used various variants of the command below, in a cleaned repository): ```console $ git submodule update --init error: submodule git dir '/home/aspiwack/projects/tweag/ghc/master/.git/modules/hadrian/vendored/Cabal' is inside git dir '/home/aspiwack/projects/tweag/ghc/master/.git/modules/hadrian' fatal: refusing to create/use '/home/aspiwack/projects/tweag/ghc/master/.git/modules/hadrian/vendored/Cabal' in another submodule's git dir Failed to clone 'hadrian/vendored/Cabal'. Retry scheduled error: submodule git dir '/home/aspiwack/projects/tweag/ghc/master/.git/modules/hadrian/vendored/Cabal' is inside git dir '/home/aspiwack/projects/tweag/ghc/master/.git/modules/hadrian' fatal: refusing to create/use '/home/aspiwack/projects/tweag/ghc/master/.git/modules/hadrian/vendored/Cabal' in another submodule's git dir Failed to clone 'hadrian/vendored/Cabal' a second time, aborting ``` Please advise on how to get unblocked. And, if I'm allowed to conclude with a plea: please be careful not to abuse Git's submodule system, it's wonky enough when used simply. -- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.

4 4

HIE using ideclImplicit
by Brandon Allbery 15 Aug '24

15 Aug '24

I've been sitting on a potential proposal to enable per-import disabling of -Wunused-imports and -Wmissing-import-lists for a while now, and https://mail.haskell.org/pipermail/haskell-cafe/2024-August/136852.html has me thinking of moving forward with it. It turns out that this would be very easy to implement within ghc, as the ideclImplicit field of ideclExt (itself a field of ImportDecl) already does what's needed; it exists to track the implicit Prelude import, and would be almost trivial to set when parsing an import. I did a check to see if anything used it as a proxy for "this is the Prelude", and everything that wants that explicitly looks for the Prelude module, with one exception: HIE information excludes anything from an import with ideclImplicit set. My questions are: 1. Is this (omitting imports with ideclImplicit) even sane? What happens with HIE information when Prelude definitions are used in the module? 2. Is this use of ideclImplicit going to cause problems with my proposed use? 2a. Should HIE be checking explicitly for Prelude as other things do, or is it more correct for other imports with ideclImplicit set to be treated the same way? -- brandon s allbery kf8nh allbery.b(a)gmail.com

1 1

How to implement type-level list concatenation as a GHC primitive type family
by Hécate 10 Aug '24

10 Aug '24

Hi GHC devs, I was wondering recently, considering that type family evaluation is notoriously slow, how one would implement type-level list concatenation directly within GHC in a way that is much less expensive to run. So I am looking for pointers, as this part of GHC is fairly unknown to me. Thinking about it, I'm actually unsure where the tyfam evaluation is happening. Any advice would be appreciated. Cheers, Hécate -- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD

4 4

GHC 9.12 release schedule
by Zubin Duggal 08 Aug '24

08 Aug '24

Hi all, We are in the process of planning the GHC 9.12 release. The tentative schedule is a fork date in mid September with a final release in late November. If you are working on any major patches that should be included in this release, please be in touch. Furthermore, please ensure that all appropriate tickets or MRs are appropriately tagged with the %9.12.1 milestone (https://gitlab.haskell.org/ghc/ghc/-/milestones/393) You can also use the release tracking ticket for further discussion: https://gitlab.haskell.org/ghc/ghc/-/issues/25123 Cheers, Zubin

3 2

Reinstallable - base
by Simon Peyton Jones 07 Aug '24

07 Aug '24

Dear GHC devs Given the now-agreed split between ghc-internal and base <https://github.com/haskellfoundation/tech-proposals/pull/51>, what stands in the way of a "reinstallable base"? Specifically, suppose that - GHC 9.8 comes out with base-4.9 - The CLC decides to make some change to `base`, so we get base-4.10 - Then GHC 9.10 comes out with base-4.10 I think we'd all like it if someone could use GHC 9.10 to compile a library L that depends on base-4.9 and either L doesn't work at all with base-4.10, or L's dependency bounds have not yet been adjusted to allow base-4.10. We'd like to have a version of `base`, say `base-4.9.1` that has the exact same API as `base-4.9` but works with GHC 9.10. Today, GHC 9.10 comes with a specific version of base, *and you can't change it*. The original reason for that was, I recall, that GHC knows the precise place where (say) the type Int is declared, and it'll get very confused if that data type definition moves around. But now we have `ghc-internal`, all these "things that GHC magically knows" are in `ghc-internal`, not `base`. *Hence my question: what (now) stops us making `base` behave like any other library*? That would be a big step forward, because it would mean that a newer GHC could compile old libraries against their old dependencies. (Some changes would still be difficult. If, for example, we removed Monad and replaced it with classes Mo1 and Mo2, it might be hard to simulate the old `base` with a shim. But getting 99% of the way there would still be fantastic.) Simon

15 24

How to get unfoldings inside a GHC plugin
by Jonathan Arnoult 06 Aug '24

06 Aug '24

Hello, I am working on Liquid Haskell, and I'd like to use the unfoldings of definitions located in interface files to unfold them in proofs. Liquid Haskell is a GHC plugin that runs in the type checking phase at the moment, and for analysis purposes it also compiles the module down to Core. I have found that unfolding information is available in the mi_decls field of ModIface, and in the field realUnfoldingInfo of IdInfo. However, my first attempts to grab for these fields yield no unfoldings either because they have been erased (mi_decls is filled with an error call in loadInterface) or they were not constructed to begin with (realUnfoldingInfo is set to NoUnfolding). In my setting, I have the name of a function, and I would need to retrieve the unfoldings (if they exist) from some environment. Does this environment exist already that is reachable to a plugin? Or do I need to construct it somehow? I also found that GHC makes a distinction between interface files in external packages and the home package, while I really would like to get the unfolding from wherever they happen to be. Any advice is appreciated.

2 1

GitLab Approval
by Jose Lane 06 Aug '24

06 Aug '24

I am looking to get my gitlab account approved. user name: Forist2034

2 1

Question about profiling reports
by Celeste Hollenbeck 05 Aug '24

05 Aug '24

Hi GHC Team, I have a question for a research project. I'm looking at GHC's profiler, and the documentation says a profiling report displays "a break-down by cost centre of the most costly functions in the program". Here's an example of the report that I'm talking about: MAIN MAIN 102 0 0.0 0.0 100.0 100.0 CAF GHC.IO.Handle.FD 128 0 0.0 0.0 0.0 0.0 CAF GHC.IO.Encoding.Iconv 120 0 0.0 0.0 0.0 0.0 CAF GHC.Conc.Signal 110 0 0.0 0.0 0.0 0.0 CAF Main 108 0 0.0 0.0 100.0 100.0 main Main 204 1 0.0 0.0 100.0 100.0 fib Main 205 2692537 100.0 100.0 100.0 100.0 This example is under Section 8.1 of the GHC User's Guide https://downloads.haskell.org/ghc/latest/docs/users_guide/profiling.html#:~…'s%20profiling%20system%20assigns%20costs,to%20the%20enclosing%20cost%20centre. It looks like the numbers often add up to less than 100% for the %time, but I don't see any documentation on a threshold for what makes a cost centre "costly"—so I assume that "costly" means that it takes up any time whatsoever, and any cost centres that take up any time at all are included in the report? So perhaps the numbers under %time don't add up to 100% all the time because of rounding error or perhaps garbage collection? Or something else that is not profiled? Is that correct? Thanks, Celeste

3 2

Acknowledgement of CI instability
by Sam Derbyshire 05 Aug '24

05 Aug '24

Hi all, The GHC team would like to acknowledge some ongoing CI instabilities in the GHC project: - regular failures of the i386 job, possibly related to the bump to debian 12 <https://gitlab.haskell.org/ghc/ghc/-/commit/203830065b81fe29003c1640a354f11…> (although the job still failed occasionally before this), - flakiness of the MultiLayerModulesDefsGhciReload test causing the fedora33-release job to fail, - lack of availability of darwin runners, causing aarch64-darwin and x86_64-darwin jobs to time out. These issues are currently causing a string of marge batch failures, holding up several MRs. We are currently short on resources for addressing problems with CI, so please bear with us while we sort the situation out. In the meantime, feel free to let us know of any other CI issues that are impacting your work on GHC. Best, Sam

3 2

Zero Multiplicities for Linear Haskell
by Zullo, Joseph Anthony 02 Aug '24

02 Aug '24

Hello GHC developers, I am Joseph Zullo, a PhD student at Purdue University. I am newly subscribed to this mailing list and my approval for GitLab is awaiting approval: my username is jazullo. I may be interested in adding Zero as a multiplicity to Linear Haskell as discussed in the source code notes<https://github.com/ghc/ghc/blob/e258ad546d96fcfffd525f9b51d237cee467ad73/co…>. My current use-case is with Liquid Haskell: I have Liquid Haskell proof terms embedded in linearly typed procedures, but the "ghost" proof terms consume terms nonlinearly even though they have no bearing on the linear style of the procedure (a binary "?" operator is used with terms to the left and proofs to the right). I am looking for any work arounds for this issue, or for any help or interest in adding zero as a multiplicity so that proof terms can be casted as non-consuming. Let me know if there are any proper avenues for this problem and/or proposal. I greatly appreciate any direction or assistance. Joseph

3 2