May 2022 - ghc-devs - Haskell.org

Implementing a compilation server
by Domínguez, Facundo 11 Oct '22

11 Oct '22

Dear ghc devs, I'm using the ghc API to write a compilation server (a.k.a. persistent worker). The idea is to serve requests to compile individual modules. In this fashion, we can compile modules with different compilation flags and yet pay only once for the startup overheads of the compiler. One challenge of this approach is to reuse as much as possible from the ghc API session/environment from one compilation request to the next, so we save the trouble of reconstructing it each time. This message is to ask for advise on how to better accomplish this reuse. I tried reusing the whole environment for multiple requests, but I'm conjecturing that this might cause troubles when the requests require building modules with different values of -this-unit-id. Another problem that streams from this is that recompiling a module which defines a type class instance fails because it encounters in the environment the type class instance from the previous compilation. My work-in-progress implementation is here [1]. There appears to be multiple ways to compile a module in the API, so far I have been trying DriverPipeline.compileFile. My best lead right now is to look for inspiration in how GHCi implements the load command, but this does a sort of --make compilation while I'm going here for the one-shot style. Thanks in advance, Facundo [1] https://github.com/tweag/rules_haskell/blob/16ba422457ea4daa5dbf40d46327ebc…

2 3

Question about ambiguous predicates in pattern bindings
by Benjamin Redelings 16 Aug '22

16 Aug '22

Hi, 1. I'm reading "A Static semantics for Haskell" and trying to code it up. I came across some odd behavior with pattern bindings, and I was wondering if someone could explain or point me in the right direction. Suppose you have the declaration (x,y) = ('a',2) My current code is yielding: x :: Num a => Char y :: Num a => a However, I notice that ghci gives x the type Char, with no constraint, which is what I would expect. It also gives y the type 'Num b => b', so I don't think it is defaulting a to Int here. The weird results from my code stem from rule BIND-PRED in Figure 15 of https://homepages.inf.ed.ac.uk/wadler/papers/staticsemantics/static-semanti… E |- bind ~~> \dicts : theta -> monobinds in bind : (LIE_{encl}, theta => LVE) Here theta = ( Num a ) and LVE = { x :: Char, y :: a }. So, theta => LVE is { x :: Num a => Char, y :: Num a => a } The obvious thing to do is avoid changing a type T to Num a => T if T does not contain a. Also I'm not totally sure if that trick gets to the bottom of the issue. However, the paper doesn't mention define theta => LVE that way. Is there something else I should read on this? 2. If we just chop out predicates which mention variables not in the type ( == ambiguous predicates?) then I'm not totally sure how to create code for this. I would imagine that we have something like tup dn = ('a', fromInteger dn 2) x = case (tup dn) of (x,y) -> x y dn case (tup dn) of (x,y) -> y In this case its not clear where to get the `dn` argument of `tup` from, in the definition of `x`. Can we pass in `undefined`? Should we do something else? If anyone can shed light on this, I would be grateful :-) -BenRI

4 8

Tracking intermittently failing CI jobs
by Bryan 12 Jul '22

12 Jul '22

Hi all, I'd like to get some data on weird CI failures. Before clicking "retry" on a spurious failure, please paste the url for your job into the spreadsheet you'll find linked at https://gitlab.haskell.org/ghc/ghc/-/issues/21591. Sorry for the slight misdirection. I wanted the spreadsheet to be world-writable, which means I don't want its url floating around in too many places. Maybe you can bookmark it if CI is causing you too much trouble. :) -Bryan

2 1

Haddock needs help
by Hécate 09 Jun '22

09 Jun '22

Hi everyone, Haddock needs help. Since I joined the Haddock team to help triage the tickets and interact with the community, we lost all of our experts, and I didn't have time to level up quickly enough to handle the mass of incoming tickets, let alone actually reduce the number of tickets to number below two hundred. As things stand now, the Haddock code base is in a disastrous state, largely not understood and its CI is in shambles. There are things that we can improve on the short and longer term – see https://github.com/haskell/haddock/issues/1465 – but the greater lack of expertise means that any project involving some core business logic is bound to be utterly and unnecessarily painful. The Hi Haddock GSOC proposal, whilst fully implemented in GHC, cannot be brought in Haddock at this moment in a reasonable timeline without any help. At present time, I need: * People who can refactor the code base, following modern software engineering practices, like domain-driven design and test-driven development. * UI developers, proficient in CSS and web accessibility. If you feel like you fit some of these criteria, please do contact me at this address. If your company can spare some engineering hours for you to give a hand, you're most welcome to do so. Just so we are clear, I am immensely grateful to the people who have submitted fixes and patches these past months, but this situation is untenable. Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD

3 3

Deep Subsumption Proposal
by Matthew Pickering 31 May '22

31 May '22

Hi all, I draw everyone's attention to the Deep Subsumption Proposal. The proposal invites the community to comment on a technical solution to the issues introduced by the simplified subsumption proposal. https://github.com/ghc-proposals/ghc-proposals/pull/511 Cheers, Matt

1 0

[Haskell] [ANNOUNCE] GHC 9.2.3 released
by Zubin Duggal 27 May '22

27 May '22

The GHC developers are very happy to at announce the availability of GHC 9.2.3. Binary distributions, source distributions, and documentation are available at [`downloads.haskell.org`](https://downloads.haskell.org/ghc/9.2.3). Download Page: https://www.haskell.org/ghc/download_ghc_9_2_3.html Blog Post: https://www.haskell.org/ghc/blog/20220527-ghc-9.2.3-released.html This release includes many bug-fixes and other improvements to 9.2.2 including: * A fix to a critical linking bug on Windows causing the 9.2.2 release to be unusable (#21196). * Numerous bug fixes for regressions and other issues in the typechecker (#2147, #21515, #20582, #20820, #21130, #21479). * Correctness bugs in the code generator and compiler backends (#21396, #20959, #21465). * Packaging fixes on many platforms (#20760, #21487, #21402). * Many others. See the [release notes][] for a full list. As some of the fixed issues do affect correctness users are encouraged to upgrade promptly. We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket] if you see anything amiss. Happy compiling, - Zubin [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [release notes]: https://downloads.haskell.org/ghc/9.2.3/docs/html/users_guide/9.2.3-notes.h…

3 4

GHC.X.Hackage and GHC's release cycle
by Ben Gamari 27 May '22

27 May '22

Hello all, Recently in the Haskell Foundation's stability working group we have been discussing various practical issues that Haskell users and prospective adopters encounter around the ecosystem. During these discussions the topic of GHC's release schedule and the ecosystem's process migration to new GHC releases has come up repeatedly. To address some of these issues, I have opened a pair of somewhat-related HF Tech Proposals: * the GHC.X.Hackage proposal ([ghc.x.hackage]) seeks to extend the [head.hackage] infrastructure used to test GHC to enable use by library maintainers in porting and testing their libraries on new GHC releases. * the [tick-tock] release proposal seeks to provide better guidance to users needing long release lifecycles by designating every other release as a "long-term support" release, with 18-month backport window. Given the wide applicability of these proposals we hope to gather feedback from a broad swath of the community. If you have questions, opinions, or concerns on either, please leave your feedback on the respective proposal. We look forward to hearing from you. Thanks! - Ben [ghc.x.hackage]: https://github.com/haskellfoundation/tech-proposals/pull/27 [head.hackage]: https://ghc.gitlab.haskell.org/head.hackage/ [tick-tock]: https://github.com/haskellfoundation/tech-proposals/pull/34

1 0

Type vs Constraint
by Simon Peyton Jones 26 May '22

26 May '22

Dear GHC devs and core libraries committee Can I draw your attention to https://gitlab.haskell.org/ghc/ghc/-/issues/21623 This ticket makes specific proposals for how to move forward on the long-standing, and increasingly painful issue of *whether or not Constraint and Type are equal in GHC's type system*. We'd love to know what you think. Please respond on the ticket. The changes affect only GHC internals, so we aren't planning a GHC proposal, but the ticket is essentially a full proposal anyway. It affects only GHC internals, but there are some users who rely on GHC internals, which is why we are seeking your opinions. Thanks Simon

1 0

9.4 branch build failure on ByteString/Internal.hs
by Shayne Fletcher 24 May '22

24 May '22

i've found for the last couple of weeks, the 9.4 branch fails to build with the following error. is this known? a fix in the works? ``` libraries/bytestring/Data/ByteString/Internal.hs:292:23: error: • Couldn't match type ‘m’ with ‘TH.Q’ ‘m’ is a rigid type variable bound by the type signature for: TH.lift :: forall (m :: * -> *). TH.Quote m => ByteString -> m TH.Exp at libraries/bytestring/Data/ByteString/Internal.hs:292:3-6 Expected type: m TH.Exp Actual type: TH.Q TH.Exp • In the expression: [| unsafePackLenLiteral |] `TH.appE` TH.litE (TH.integerL (fromIntegral len)) `TH.appE` TH.litE (TH.BytesPrimL $ TH.Bytes ptr 0 (fromIntegral len)) In an equation for ‘TH.lift’: TH.lift (BS ptr len) = [| unsafePackLenLiteral |] `TH.appE` TH.litE (TH.integerL (fromIntegral len)) `TH.appE` TH.litE (TH.BytesPrimL $ TH.Bytes ptr 0 (fromIntegral len)) In the instance declaration for ‘TH.Lift ByteString’ • Relevant bindings include lift :: ByteString -> m TH.Exp (bound at libraries/bytestring/Data/ByteString/Internal.hs:292:3) | 292 | lift (BS ptr len) = [| unsafePackLenLiteral |] | ^^^^^^^^^^^^^^^^^^^^^^^^^^... ``` -- Shayne Fletcher

1 1

GHC 9.4.1-alpha2 now available
by Ben Gamari 24 May '22

24 May '22

The GHC developers are happy to announce the availability of the second alpha release of the GHC 9.4 series. Binary distributions, source distributions, and documentation are available at downloads.haskell.org: https://downloads.haskell.org/ghc/9.4.1-alpha2 This major release will include: - A new profiling mode, `-fprof-late`, which adds automatic cost-center annotations to all top-level functions *after* Core optimisation has run. This incurs significantly less performance cost while still providing informative profiles. - A variety of plugin improvements including the introduction of a new plugin type, *defaulting plugins*, and the ability for typechecking plugins to rewrite type-families. - An improved constructed product result analysis, allowing unboxing of nested structures, and a new boxity analysis, leading to less reboxing. - Introduction of a tag-check elision optimisation, bringing significant performance improvements in strict programs. - Generalisation of a variety of primitive types to be levity polymorphic. Consequently, the `ArrayArray#` type can at long last be retired, replaced by standard `Array#`. - Introduction of the `\cases` syntax from [GHC proposal 0302] - A complete overhaul of GHC's Windows support. This includes a migration to a fully Clang-based C toolchain, a deep refactoring of the linker, and many fixes in WinIO. - Support for multiple home packages, significantly improving support in IDEs and other tools for multi-package projects. - A refactoring of GHC's error message infrastructure, allowing GHC to provide diagnostic information to downstream consumers as structured data, greatly easing IDE support. - Significant compile-time improvements to runtime and memory consumption. - On overhaul of our packaging infrastructure, allowing full traceability of release artifacts and more reliable binary distributions. - ... and much more. See the [release notes] for a full accounting. Note that, as 9.4.1 is the first release for which the released artifacts will all be generated by Hadrian, it's possible that there will be packaging issues. If you enounter trouble while using a binary distribution, please open a [ticket]. Likewise, if you are a downstream packager, do consider migrating to [Hadrian] to run your build; the Hadrian build system can be built using `cabal-install`, `stack`, or the in-tree [bootstrap script]. We would like to thank Microsoft Azure, GitHub, IOHK, the Zw3rk stake pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket] if you see anything amiss. Happy testing, - Ben [GHC proposal 0302]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0302-c… [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [bootstrap script]: https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d1… [release notes]: https://downloads.haskell.org/~ghc/9.4.1-alpha2/docs/users_guide/9.4.1-note…

1 0