June 2024 - ghc-devs - Haskell.org

Request for approval of account
by Mark Seemann 24 Jun '25

24 Jun '25

Hello I’d like to report a bug in GHC because an error message tells me to do so. In order to do that, I’m trying to follow the guidelines in https://gitlab.haskell.org/ghc/ghc/-/wikis/report-a-bug, so I’ve created an account. The next step, as I understand it, is to use this mailing list to request approval for he account. I’m hereby doing that. TIA Mark Seemann

2 1

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

Call for Talks: Haskell Implementors' Workshop 2024
by Matthew Pickering 08 Jul '24

08 Jul '24

``` ACM SIGPLAN Haskell Implementors' Workshop https://icfp24.sigplan.org/home/hiw-2024 Milan, Italy, September 2, 2024 Co-located with ICFP 2024 https://icfp24.sigplan.org/ ``` ## Important dates * Deadline: July 19, 2024 (AoE) * Notification: August 2, 2024 * Workshop: September 2, 2024 The 16th Haskell Implementors’ Workshop is to be held alongside ICFP 2024 this year in Milan. It is a forum for people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure to share their work and to discuss future directions and collaborations with others. Talks and/or demos are proposed by submitting an abstract, and selected by a small program committee. There will be no published proceedings. The workshop will be informal and interactive, with open spaces in the timetable and room for ad-hoc discussion, demos, and lightning talks. ## Scope and Target Audience It is important to distinguish the Haskell Implementors’ Workshop from the Haskell Symposium which is also co-located with ICFP 2024. The Haskell Symposium is for the publication of Haskell-related research. In contrast, the Haskell Implementors’ Workshop will have no proceedings – although we will aim to make talk videos, slides, and presented data available with the consent of the speakers. The Implementors’ Workshop is an ideal place to describe a Haskell extension, describe works-in-progress, demo a new Haskell-related tool, or even propose future lines of Haskell development. Members of the wider Haskell community are encouraged to attend the workshop – we need your feedback to keep the Haskell ecosystem thriving. Students working with Haskell are especially encouraged to share their work. The scope covers any of the following topics. There may be some topics that people feel we’ve missed, so by all means submit a proposal even if it doesn’t fit exactly into one of these buckets: * Compilation techniques * Language features and extensions * Type system implementation * Concurrency and parallelism: language design and implementation * Performance, optimization and benchmarking * Virtual machines and run-time systems * Libraries and tools for development or deployment ## Talks We invite proposals from potential speakers for talks and demonstrations. We are aiming for 20-minute talks with 5 minutes for questions and changeovers. We want to hear from people writing compilers, tools, or libraries, people with cool ideas for directions in which we should take the platform, proposals for new features to be implemented, and half-baked crazy ideas. Please submit a talk title and abstract of no more than 300 words. Submissions can be made via HotCRP at https://hiw2024.hotcrp.com until July 19 (anywhere on earth). We will also have a lightning talks session. These have been very well received in recent years, and we aim to increase the time available to them. Lightning talks should be ~7mins and are scheduled on the day of the workshop. Suggested topics for lightning talks are to present a single idea, a work-in-progress project, a problem to intrigue and perplex Haskell implementors, or simply to ask for feedback and collaborators. ## Program Committee * Matthew Pickering (Well-Typed LLP) * David Binder (University of Tübingen) * Gabriella Gonzalez (Mercury) * Sylvain Henry (IOG) * Teofil Camarasu (Tracsis) ## Contact * Matthew Pickering

1 1

Deriving via TH (#12457)
by Sebastian Graf 24 Jun '24

24 Jun '24

Hi Ryan and GHC devs, I'm working on-and-off on a prototype that enables use of TemplateHaskell as a deriving strategy: https://gitlab.haskell.org/ghc/ghc/-/commit/82aea77ed908fe36bed829c9c4a01ea…. My current working example is: ``` {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE TypeFamilies #-} module T12457A where import GHC.Internal.TH.Lib import GHC.Internal.TH.Syntax class C a where type Assoc a m :: a -> Int n :: a -> Int instance DeriveTH C where deriveTH _p head = do let AppT (ConT t) (VarT a) = head x <- newName "x" x2 <- newName "x" addTopDecls =<< [d| $(varP x) = 12 $(varP x2) = 23 |] [d| instance C $(varT a) => C ($(conT t) $(varT a)) where type Assoc ($(conT t) $(varT a)) = Char m :: Eq a => a -> Int m _ = $(varE x) + 42 {-# INLINE m #-} n :: Show a => a -> Int n _ = $(varE x2) + 13 |] --- {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE DerivingStrategies #-} module T12457 where import Language.Haskell.TH import GHC.Internal.TH.Lib import T12457A newtype T a = T [a] deriving th C ``` I just managed to implement `GHC.Tc.Deriv.Infer.inferConstraints` for this mechanism (still hacky and broken in many ways) and am now stuck in `Deriv.genFamInst`. I realised I would need to replicate the first half of `tcClsInstDecl` to implement it. Before long, I will probably also need to replicate the other half to check method bindings. That leaves me wondering: Is it a good idea to integrate this new deriving strategy so tightly with the existing deriving framework? I would rather just call `tcClsInstDecl`, do a bit of sanity checking for specified constraints in standalone deriving declarations and call it a day. Given that you are the architect of our current deriving code, I hope you are the right person to ask for input. Thanks, Sebastian

2 3

HsCmdArrForm Fixity
by Alan & Kim Zimmerman 21 Jun '24

21 Jun '24

We are currently wrapping up https://gitlab.haskell.org/ghc/ghc/-/merge_requests/12842, which moves Fixity declarations into TTG extensions point, and into the haskell syntax, not GHC. But rnCmd for HsCommandArrForm in current master has rnCmd (HsCmdArrForm _ op _ (Just _) [arg1, arg2]) ... It matches on HsCmd GhcPs, which never introduce the `Just` form for fixity. The only place the `Just` form is introduced, is in mkOpFormRn, but this is only ever called from this specific equation. So both can be removed, without changing behaviour. The question is, this code was added for a reason at some point, what has broken in the meantime? Should this be fixed somehow instead of being removed? Alan

2 1

TTG and annotations
by Simon Peyton Jones 19 Jun '24

19 Jun '24

Hi Alan I know that you are continuing to work hard on annotations in the TTG extension fields -- thank you. As you know, I'm very eager to get a big Note to explain how it all works. At the moment I am completely lost, and I am reduced to cargo-culting code by copy/pasting and hoping for the best. Plus we are over-reliant on you, which isn't really fair on you. Several of us (including me and Rodrigo, and doubtless other ghc-devs, cc'd) would be happy to review, edit, and improve -- but it is hard for us to see the "big picture". Could you see your way to drafting something? It need not be that long initially, but having *something* to ask questions about and improve would be super helpful. I suggest drafting it in a Google doc so it was easy to edit, and for others to contribute to, but ultimately it should be in the repo. Thanks! Simon

2 1

embedded hashes in library names
by Shayne Fletcher 13 Jun '24

13 Jun '24

when i use ghcup to install a distribution, the libraries that result have embedded hashes in their names e.g. the -f942 in libHSghc-prim-0.11.0-f942-ghc9.10.1.so. is there some way to disable this so that for example in this case, i'd get libHSghc-prim-0.11.0-ghc9.10.1.so? -- Shayne Fletcher

1 1

A dashboard for fragile tests
by Bryan Richter 10 Jun '24

10 Jun '24

Hi all, This weekend at Zurihac, I wanted to start making it possible to explore fragile tests. Fragile tests are tests that pass nondeterministically. Marking them fragile means that they do not influence the overall success of the testsuite. It's been a way of sweeping problems under the rug. For a few years, the GHC test infrastructure has been recording fragile test results into a database. We record whether the test passed or failed. Now we can start peeking under the rug to see what kind of patterns have developed. I was mostly interested in whether or not fragile tests are truly fragile. It looks like many are not. The dashboard has bucketed results into months. Every cell shows the pass rate for a given month (column) and test (row). Red cells mean 0% success. Green cells, 100% success. Shades of yellow are everything in between. It's remarkable how much green there is. One would assume even fragile tests would fail for legitimate reasons sometimes! At this point, the visualization is mostly good for seeing large trends. Any other observations would be appreciated! The dashboard is interactive at https://grafana.gitlab.haskell.org/goto/XcuO3ZUIg?orgId=2 [image: image.png] -Bryan

1 0

Changes to HIE File due to ApplicativeDo going via HsExpansions
by Ingle, Apoorv N 09 Jun '24

09 Jun '24

Dear ghc-devs, For past few months I’ve been working on Rebindable Syntax<https://gitlab.haskell.org/ghc/ghc/-/wikis/Rebindable-syntax>, specifically on expanding ApplicativeDo (#24406, MR !12066<https://gitlab.haskell.org/ghc/ghc/-/merge_requests/12066>) statements before type checking. I noticed that there is a failing test case related to HIE files (T23540). I have been unsuccessful in debugging why this happens and/or if this has any effect on the users of HIE files. Can anyone who has experience in this area be able to take a look and guide me? Thanks! Apoorv

2 1

Blog post: working towards a more stable Template Haskell
by Teofil Camarasu 07 Jun '24

07 Jun '24

Hi folks, I’ve written up a blog post about our ongoing project to improve the stability of Template Haskell. The post lays out: - why users of Template Haskell often face broken code with each new version of the compiler. - some of our plans to make the interface more stable. - some groundwork we’ve lain to make these plans achievable - ways folks can get invovled Give it a read: https://informal.codes/posts/stabilising-th/ Cheers, Teo

2 1