- ghc-devs - Haskell.org

The reason for non-GHC boot dependencies
by Hécate 11 Jul '24

11 Jul '24

Hi devs, I had a chat earlier today with someone and found myself unable to explain the reason why GHC came with boot dependencies like xhtml, that are dependencies of Haddock and HPC. Obviously, the binaries are (haskell-)dynamically linked when distributed, but what is the reason why haddock, hpc, etc can't be (haskell-)statically linked when distributed? Surely the size of binaries can't be the only concern, otherwise we'd use upx¹ on them when distributing them. Cheers, Hécate 1: https://upx.github.io -- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD

5 8

Cannot build `master`, tries to use GHC 9.2?!
by ÉRDI Gergő 11 Jul '24

11 Jul '24

Hi, I'm trying to build GHC 5b1aefb70edbd54ac899896df39d8f3d6c579518 but I'm running into a weird problem. Using `hadrian/build-stack`, it fails quite early on with: | Run Ghc CompileCWithGhc (Stage0 GlobalLibs): utils/hsc2hs/cbits/utils.c => _build/stageBoot/utils/hsc2hs/build/c/cbits/utils.o Command line: ghc -Wall -hisuf hi -osuf o -hcsuf hc -static -hide-all-packages -no-user-package-db '-package-env -' '-package-db _build/stageBoot/inplace/package.conf.d' '-this-unit-id hsc2hs-0.68.10-inplace' '-this-package-name hsc2hs' '-package-id base-4.16.4.0' '-package-id containers-0.6.5.1' '-package-id directory-1.3.6.2' '-package-id filepath-1.4.2.2' '-package-id process-1.6.16.0' -i -i/home/cactus/prog/haskell/ghc/ghc.master/_build/stageBoot/utils/hsc2hs/build -i/home/cactus/prog/haskell/ghc/ghc.master/_build/stageBoot/utils/hsc2hs/build/hsc2hs/autogen -i/home/cactus/prog/haskell/ghc/ghc.master/utils/hsc2hs/src/ -I_build/stageBoot/utils/hsc2hs/build -I/home/cactus/.ghcup/ghc/9.2.8/lib/ghc-9.2.8/process-1.6.16.0/include -I/home/cactus/.ghcup/ghc/9.2.8/lib/ghc-9.2.8/unix-2.7.2.2/include -I/home/cactus/.ghcup/ghc/9.2.8/lib/ghc-9.2.8/time-1.11.1.1/include -I/home/cactus/.ghcup/ghc/9.2.8/lib/ghc-9.2.8/bytestring-0.11.4.0/include -I/home/cactus/.ghcup/ghc/9.2.8/lib/ghc-9.2.8/base-4.16.4.0/include -I/home/cactus/.ghcup/ghc/9.2.8/lib/ghc-9.2.8/ghc-bignum-1.2/include -I/home/cactus/.ghcup/ghc/9.2.8/lib/ghc-9.2.8/include -optP-include -optP_build/stageBoot/utils/hsc2hs/build/hsc2hs/autogen/cabal_macros.h -optP-DIN_GHC_TREE -outputdir _build/stageBoot/utils/hsc2hs/build -fdiagnostics-color=always -Wall -XHaskell2010 -optc-I_build/stageBoot/utils/hsc2hs/build -optc-I/home/cactus/.ghcup/ghc/9.2.8/lib/ghc-9.2.8/process-1.6.16.0/include -optc-I/home/cactus/.ghcup/ghc/9.2.8/lib/ghc-9.2.8/unix-2.7.2.2/include -optc-I/home/cactus/.ghcup/ghc/9.2.8/lib/ghc-9.2.8/time-1.11.1.1/include -optc-I/home/cactus/.ghcup/ghc/9.2.8/lib/ghc-9.2.8/bytestring-0.11.4.0/include -optc-I/home/cactus/.ghcup/ghc/9.2.8/lib/ghc-9.2.8/base-4.16.4.0/include -optc-I/home/cactus/.ghcup/ghc/9.2.8/lib/ghc-9.2.8/ghc-bignum-1.2/include -optc-I/home/cactus/.ghcup/ghc/9.2.8/lib/ghc-9.2.8/include -optc-Wno-error=inline -c utils/hsc2hs/cbits/utils.c -o _build/stageBoot/utils/hsc2hs/build/c/cbits/utils.o -O -H32m ===> Command failed with error code: 1 ghc: unrecognised flag: -this-package-name hsc2hs I don't know where all those references to GHC 9.2.8 come from. I've run `configure` with GHC 9.10.1 on the $PATH and it correctly reports it as the bootstrapping version: Bootstrapping using : ghc which is version : 9.10.1 What am I doing wrong? Gergo

1 2

Cabal woe
by Simon Peyton Jones 11 Jul '24

11 Jul '24

Friends I'm trying to repro #25064 with my development build of GHC. The test case depends on packages `primitive` and `hashtables`. So I try this (see below). Alas, apparently after the `cabal install`, it can't find Prelude. What should I do? I tried removing the "environments" file, whatever that is, which then meant it could find Prelude -- but the libraries were no longer installed. I lack a decent model of what is going on with installing packages for my development builds. Is there a write up anywhere? Thanks Simon bash$ cabal install --lib hashtables primitive --with-compiler $HOME/code/HEAD/$s2 Warning: Unknown/unsupported 'ghc' version detected (Cabal 3.10.1.0 supports 'ghc' version < 9.8): /home/simonpj/code/HEAD/_build/stage1/bin/ghc is version 9.11.20240517 Warning: Unknown/unsupported 'ghc' version detected (Cabal 3.10.1.0 supports 'ghc' version < 9.8): /home/simonpj/code/HEAD/_build/stage1/bin/ghc is version 9.11.20240517 Resolving dependencies... bash$ ~/code/HEAD/$s2 -c T25064.hs Loaded package environment from T25064.hs:1:8: error: [ ]8;;https://errors.haskell.org/messages/GHC-87110 \GHC-87110 ]8;; \] Could not load module ‘Prelude’. It is a member of the hidden package ‘base-4.20.0.0’. Use -v to see a list of the files searched for. | 1 | module Bug where | ^^^ bash$ rm /home/simonpj/.ghc/x86_64-linux-9.11.20240517/environments/default bash$ ~/code/HEAD/$s2 -c T25064.hs T25064.hs:3:1: error: [ ]8;;https://errors.haskell.org/messages/GHC-61948 \GHC-61948 ]8;; \] Could not find module ‘Control.Monad.Primitive’. Perhaps you meant Control.Monad.Writer (from mtl-2.3.1) Use -v to see a list of the files searched for. | 3 | import Control.Monad.Primitive | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ T25064.hs:4:1: error: [ ]8;;https://errors.haskell.org/messages/GHC-87110 \GHC-87110 ]8;; \] Could not find module ‘Data.HashTable.ST.Basic’. Use -v to see a list of the files searched for. | 4 | import qualified Data.HashTable.ST.Basic as H | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

11 20

Sunsetting CentOS support
by Andreas Klebinger 10 Jul '24

10 Jul '24

Hello devs, with CentOS 7 reaching EOL we are demoting it to a Tier 2 platform and will eventually drop support completely. There are no immediate plans to stop supporting it, but we will not allocate any more resources towards support for it and will likely drop support completely should it break in the future. We introduced support for Rocky Linux as replacement for CentOS some time ago, so users who need a RHEL compatible GHC distribution should be able to use GHC packaged for Rocky Linux instead without issues. Best Regards Andreas Klebinger

1 0

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

Re: Deriving mechanisms in GHC
by Ryan Scott 04 Jul '24

04 Jul '24

(Disclaimer: I have never used hs-to-coq before, so everything below is merely an educated guess.) Looking at the source code for hs-to-coq, I see this [1]: addDerivedInstances :: GhcMonad m => TypecheckedModule -> m > TypecheckedModule > addDerivedInstances tcm = do > let Just (hsgroup, a, b, c) = tm_renamed_source tcm > > (_gbl_env, inst_infos, _rn_binds) <- initTcHack tcm $ do > let tcg_env = fst (tm_internals_ tcm) > tcg_env_hack = tcg_env { tcg_mod = fakeDerivingMod, > tcg_semantic_mod = fakeDerivingMod } > -- Set the module to make it look like we are in GHCi > -- so that GHC will allow us to re-typecheck existing > instances > setGblEnv tcg_env_hack $ > #if __GLASGOW_HASKELL__ >= 810 > tcInstDeclsDeriv [] (hs_derivds hsgroup) > #else > tcInstDeclsDeriv [] (hs_tyclds hsgroup >>= group_tyclds) > (hs_derivds hsgroup) > #endif If I understand this code correctly, it is using the GHC API to produce deriving-generated code and typecheck it, which seems reasonable. The part that confuses me is the #if __GLASGOW_HASKELL__ >= 810 bit. Prior to GHC 8.10, this code would obtain deriving-related information from two places: 1. The deriving clauses of data type declarations (i.e., the hs_tyclds) 2. Standalone deriving declarations (i.e., the hs_derivds) In GHC 8.10 and later, however, the code only obtains deriving-related information from standalone deriving declarations. This means that you'll completely skip over any derived instances that arise from deriving clauses, which is likely the source of the trouble you're encountering. In order to give advice on what you *should* be doing, let me briefly describe why the type of tcInstDeclsDeriv changed in GHC 8.10. The commit that changed tcInstDeclsDeriv is [2]. Prior to that commit, tcInstDeclsDeriv would obtain information related to deriving clauses via its first two arguments: 1. The first argument (of type [DerivInfo]) contained all of the deriving clauses for data family instances. (Note that hs-to-coq uses an empty list, so this means that hs-to-coq will always skip over data family instances, before or after GHC 8.10. I'm not sure if this should be considered as a separate bug.) 2. The second argument (of type [LTyClDecl GhcRn]) contained all of the data type definitions, which might have deriving clauses attached to them. The linked commit changes things so that *all* deriving clause–related information (both for ordinary data types as well as data family instances) is passed as a [DerivInfo] list. This means that hs-to-coq needs to produce those DerivInfo values somehow. As inspiration, you might want to look at how GHC calls tcInstDeclsDeriv here [3]. GHC first calls the tcTyAndClassDecls function to produce the DerivInfo values, and then it passes the DerivInfo values to tcInstDeclsDeriv. I would hope that something similar would work for hs-to-coq. Best, Ryan ----- [1] https://github.com/plclub/hs-to-coq/blob/03e823972fc7c5f85a300e554c691563f8… [2] https://gitlab.haskell.org/ghc/ghc/-/commit/679427f878e50ba5a9981bac4c2f9c7… [3] https://gitlab.haskell.org/ghc/ghc/-/blob/bc1d435e399d8376b4e33d5d936424ff7…

3 3

Deriving mechanisms in GHC
by Yao Li 03 Jul '24

03 Jul '24

Dear All, My name is Yao Li. I am an assistant professor at Portland State University. I am currently working with my Ph.D. student Nicholas Coltharp on updating a tool called hs-to-coq (https://github.com/plclub/hs-to-coq) to support GHC 8.10 and the corresponding base library. However, we are running into some trouble involving the "deriving" mechanisms in GHC. It seems the derived type class instances are no longer generated by hs-to-coq after we updated GHC. I wonder what changes happened between GHC 8.4 and 8.10 that could possibly lead to this issue? Or if we hope to dig into this issue ourselves, what are some GHC resources that we should look into? Any pointers would be much appreciated! For context, hs-to-coq uses GHC's parser to parse Haskell code. Our translation is based on the source code but on the GhcRn pass. Thanks, Yao Li, Ph.D., (He/Him) Assistant Professor, Computer Science Department, Portland State University

1 0

CountDeps
by Simon Peyton Jones 02 Jul '24

02 Jul '24

Does anyone know what the CountDeps test does? I'm getting the failure below in my branch. Should I just accept it? I think it's because GHC.Core.FamInstEnv now depends on GHC.Builtin.Types.Literals, a very reasonable dependency Thanks Simon +++ "/builds/ghc/ghc/tmp/ghctest-su6yq239/test spaces/testsuite/tests/count-deps/CountDepsAst.run/CountDepsAst.run.stdout.normalised" 2024-07-01 18:37:33.372548372 +0000 @@ -2,6 +2,7 @@ GHC.Builtin.Names GHC.Builtin.PrimOps GHC.Builtin.Types +GHC.Builtin.Types.Literals GHC.Builtin.Types.Prim GHC.Builtin.Uniques GHC.ByteCode.Types --- "/builds/ghc/ghc/tmp/ghctest-su6yq239/test spaces/testsuite/tests/count-deps/CountDepsParser.run/CountDepsParser.stdout.normalised" 2024-07-01 18:37:33.393548751 +0000 +++ "/builds/ghc/ghc/tmp/ghctest-su6yq239/test spaces/testsuite/tests/count-deps/CountDepsParser.run/CountDepsParser.run.stdout.normalised" 2024-07-01 18:37:33.393548751 +0000 @@ -2,6 +2,7 @@ GHC.Builtin.Names GHC.Builtin.PrimOps GHC.Builtin.Types +GHC.Builtin.Types.Literals GHC.Builtin.Types.Prim GHC.Builtin.Uniques GHC.ByteCode.Types

2 1

[ANNOUNCE] GHC 9.6.6 is now available
by Zubin Duggal 01 Jul '24

01 Jul '24

The GHC developers are happy to announce the availability of GHC 9.6.6. Binary distributions, source distributions, and documentation are available on the [release page](https://www.haskell.org/ghc/download_ghc_9_6_6.html). Blog Post: https://www.haskell.org/ghc/blog/20240701-ghc-9.6.6-released.html This release is primarily a bugfix release addressing some issues found in the 9.6 series. These include: * A fix for a bug in the NCG that could lead to incorrect runtime results due to erroneously removing a jump instruction (#24507). * A fix for a linker error that manifested on certain platform/toolchain combinations, particularly darwin with a brew provisioned toolchain, arising due to a confusion in linker options between GHC and cabal (#22210). * A fix for a compiler panic in the simplifier due to incorrect eta expansion (#24718). * A fix for possible segfaults when using the bytecode interpreter due to incorrect constructor tagging (#24870). * And a few more fixes A full accounting of changes can be found in the [release notes]. 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, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, Haskell Foundation, 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 Hacking! -Zubin [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [release notes]: https://downloads.haskell.org/~ghc/9.6.6/docs/users_guide/9.6.6-notes.html

1 0

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