- ghc-devs - Haskell.org

Give MonadTrans a QuantifiedConstraints superclass
by Baldur Blöndal 01 Jun '21

01 Jun '21

This is to advertise the proposal (https://gitlab.haskell.org/ghc/ghc/-/issues/19922) to add a superclass to the MonadTrans type class in Control.Monad.Trans. A Monad transformer 'trans' lifts a 'Monad m' to a 'Monad (trans m)'. This proposal code-ifies that with a superclass constraint, an impliciation constraint enabled by the recent extension QuantifiedConstraints: class (forall m. Monad m => Monad (trans m)) => MonadTrans trans where .. This is the main motiviating example of the Quantified Class Constraints paper https://gkaracha.github.io/papers/quantcs.pdf

2 1

GHC releases and versions
by Sylvain Henry 28 May '21

28 May '21

Hi devs, We currently have 4 branches of GHC in flight: 8.10, 9.0, 9.2 and HEAD Latest releases: - 8.10.4: 2021/02/06 - 9.0.1: 2021/02/04 - 9.2.1-alpha2: 2021/04/23 Considering: 1) 8.10 branch should be stable but a lot of stuff has been merged for 8.10.5. To the point that 8.10.5 should probably be a "major release in the 8.10 series". 2) 9.0.1 is the latest major release but it shouldn't be used before 9.0.2 is released because of bugs and regressions (9.0.2 branch contains a fix for a critical bug in 9.0.1 [1] since March). 3) We might release 9.2.1 and 9.0.2 approximately at the same time which will be quite confusing for users ("9.0.2 in the 9.0 series and 9.2.1 in the 9.2 series"). 4) The first major number is meaningless. Proposition: Switch to A.B.C[.D] version scheme where: - A: major release ("series") - B: major release in the A series if B>0 and C=0; beta release if B=0 - C: bugfix release for A.B (if C>0) or beta release number (if B=0) - D: date when building in tree, not for releases It might be clearer exposed like this: showVersion = \case [a,b,c,d] -> "Dev version of " ++ showVersion [a,b,c] ++ " built on " ++ show d [a,0,c] -> "beta " ++ show c ++ " in series " ++ show a [a,b,0] -> "Major release " ++ show [a,b] ++ " in series " ++ show a [a,b,c] -> "Bugfix release " ++ show c ++ " for " ++ show [a,b] _ -> undefined > showVersion [9,0,1,20211028] "Dev version of beta 1 in series 9 built on 20211028" > showVersion [9,0,1] "beta 1 in series 9" > showVersion [9,0,2] "beta 2 in series 9" > showVersion [9,1,0] "Major release [9,1] in series 9" > showVersion [9,1,1] "Bugfix release 1 for [9,1]" > showVersion [9,2,0] "Major release [9,2] in series 9" > showVersion [10,1,0] "Major release [10,1] in series 10" Effects: 1) We could use C for bugfix versions which are to be released much faster than major versions. 2) B would be used for the old series we maintain. We backport a lot more stuff than before in older releases it seems, so it would be more PVP compliant to bump a major version number. 3) A would be used for the usual 6-month major releases. 4) We could make major releases in the 8 series (e.g. 8.10.5 could be released as 8.11.0) 5) We could advertise 9.0.1 as a beta (as everyone seems to consider .1 releases) 6) 9.2.1 final could be released either as 9.3 (next major in the 9 series if we just forget about 9.0.* and 9.2.*) or as 10.1.0 (first major in the 10 series). 7) No difference anymore between even/odd version numbers (for reference the current scheme is explained in [2]) Any thoughts? Sylvain [1] https://mail.haskell.org/pipermail/haskell-cafe/2021-March/133540.html [2] https://gitlab.haskell.org/ghc/ghc/-/wikis/working-conventions/releases

2 1

Errors in haddock git fetch
by Simon Peyton Jones 27 May '21

27 May '21

I'm getting these errors from `git submodule update`. Should I worry? Simon >From https://gitlab.haskell.org/ghc/haddock * [new branch] az/T19834 -> origin/az/T19834 * [new branch] az/T19834-2 -> origin/az/T19834-2 * [new branch] az/T19845 -> origin/az/T19845 * [new branch] az/T19845-2 -> origin/az/T19845-2 * [new branch] az/T19845-3 -> origin/az/T19845-3 * [new branch] dependabot/npm_and_yarn/haddock-api/resources/html/hosted-git-info-2.8.9 -> origin/dependabot/npm_and_yarn/haddock-api/resources/html/hosted-git-info-2.8.9 * [new branch] dependabot/npm_and_yarn/haddock-api/resources/html/lodash-4.17.21 -> origin/dependabot/npm_and_yarn/haddock-api/resources/html/lodash-4.17.21 * [new branch] dn/dn-driver-refactor-and-split -> origin/dn/dn-driver-refactor-and-split b4e7407b..c7281407 ghc-9.2 -> origin/ghc-9.2 dabdee14..4f9088e4 ghc-head -> origin/ghc-head * [new branch] wip/T18389-task-zero -> origin/wip/T18389-task-zero + 7d27ea7a...3b6a8774 wip/T19720 -> origin/wip/T19720 (forced update) + fe35fed3...40ba457f wip/adinapoli-align-ps-messages -> origin/wip/adinapoli-align-ps-messages (forced update) * [new branch] wip/dn-driver-refactor-and-split -> origin/wip/dn-driver-refactor-and-split error: cannot lock ref 'refs/remotes/origin/wip/hsyl20/dynflags': 'refs/remotes/origin/wip/hsyl20/dynflags/exception' exists; cannot create 'refs/remotes/origin/wip/hsyl20/dynflags' ! [new branch] wip/hsyl20/dynflags -> origin/wip/hsyl20/dynflags (unable to update local ref) * [new branch] wip/hsyl20/uncpp -> origin/wip/hsyl20/uncpp Unable to fetch in submodule path 'utils/haddock'; trying to directly fetch 4f9088e4b04e52ca510b55a78048c9230537e449: Submodule path 'utils/haddock': checked out '4f9088e4b04e52ca510b55a78048c9230537e449' simonpj@MSRC-3645512:~/code/HEAD-7$

3 2

Ampere A1 instances for builder/marge?
by Karel Gardas 26 May '21

26 May '21

Hi, just to pass https://www.servethehome.com/oracle-cloud-giving-away-ampere-arm-a1-instanc… -- oracle seems to be giving some "always free" Ampere/ARM based instances. Looks like they even have some RAM and cores so perhaps they may be usable for marge/builder for arm/linux platform? BTW: Not tested myself, not trust Oracle, but sometimes man can get some good even from ... well... Oracle... Thanks, Karel

1 0

Productivity Tip from mpickering
by Matthew Pickering 26 May '21

26 May '21

Hi, I am now using a new flavour combination which is proving *very* nice as a compromise between fast recompiles and passing tests. My normal build command is now: ./hadrian/build --flavour=default+no_profiled_libs+omit_pragmas --freeze1 -j This has the effect of * base libraries are compiled with optimisation * Profiling libraries are not built * Stage 1 compiler is compiled with -O + -fomit-interface-pragmas, so recompilation behaviour is much better. The end result is a nearly clean testsuite run (I think there are two failures) but much faster iterations when modifying `compiler/*`. Cheers, Matt

3 2

Coding style: Using StandaloneKindSignatures in GHC
by Baldur Blöndal 25 May '21

25 May '21

Discussion to permit use of StandaloneKindSignatures in the GHC coding style guide. I believe it increases the clarity of the code, especially as we move to fancier kinds. It is the only way we have for giving full signatures to type synonyms, type classes, type families and others. An example: type Cat :: Type -> Type type Cat ob = ob -> ob -> Type type Category :: forall ob. Cat ob -> Constraint class Category cat where id :: cat a a .. type Proxy :: forall k. k -> Type data Proxy a = Proxy type Some :: forall k. (k -> Type) -> Type data Some f where Some :: f ex -> Some f -- | The regular function type type (->) :: forall {rep1 :: RuntimeRep} {rep2 :: RuntimeRep}. TYPE1 rep1 -> TYPE rep2 -> Type type (->) = FUN 'Many This is in line with function definitions that are always given a top-level, standalone type signature (1) and not like we currently define type families/synonyms (2) by annotating each argument or not at all. Using -XStandaloneKindSignatures (3) matches (1) -- (1) curry :: ((a, b) -> c) -> (a -> b -> c) curry f x y = f (x, y) -- (2) type Curry (f :: (a, b) -> c) (x :: a) (y :: b) = f '(x, y) :: c -- (3) type Curry :: ((a, b) -> c) -> (a -> b -> c) type Curry f x y = f '(x, y) It covers an edgecase that `KindSignatures` don't. The only way for deriving to reference datatype arguments is if they are quantified by the declaration head -- `newtype Bin a ..`. StandaloneKindSignatures allows us to still provide a full signature. We could write `newtype Bin a :: Type -> Type` without it but not `newtype Bin :: Type -> Type -> Type` type Bin :: Type -> Type -> Type newtype Bin a b = Bin (a -> a -> b) deriving (Functor, Applicative) via (->) a `Compose` (->) a Let me know what you think

10 15

GHC head, profiling with -O2 does not work
by Harendra Kumar 23 May '21

23 May '21

Hi, I am trying to build a small program with profiling using a ghc built from haskell gitlab master branch. When I use -O2 I run into: $ ghc/inplace/bin/ghc-stage2 --make -O2 -prof -fprof-auto -rtsopts Main.hs Linking Main ... ./StreamD.o(.text+0x1b9f2): error: undefined reference to 'StreamK_mkStreamFromStream_HPC_cc' ./MArray.o(.text+0xbe83): error: undefined reference to 'StreamK_mkStreamFromStream_HPC_cc' Main.o(.text+0x6fdb): error: undefined reference to 'StreamK_mkStreamFromStream_HPC_cc' collect2: error: ld returned 1 exit status `cc' failed in phase `Linker'. (Exit code: 1) It builds fine without the -O2 option. On ghc-8 it builds fine even with -O2. Is that a bug in the head GHC or just something to do with how I built it? Thanks, Harendra

2 1

Darwin CI Status
by Matthew Pickering 20 May '21

20 May '21

Hi all, The darwin pipelines are gumming up the merge pipeline as they are taking over 4 hours to complete on average. I am going to disable them - https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5785 Please can someone give me access to one of the M1 builders so I can debug why the tests are taking so long. Once I have fixed the issue then I will enable the pipelines. Cheers, Matt

2 2

Second Call for Talks: Haskell Implementors' Workshop @ ICFP'21
by Ningning Xie 16 May '21

16 May '21

Call for Talks ACM SIGPLAN Haskell Implementors' Workshop https://icfp21.sigplan.org/home/hiw-2021 Virtual, 22 Aug, 2021 Co-located with ICFP 2021 https://icfp21.sigplan.org/ Important dates --------------- Deadline: Wednesday, 30 June, 2021 (AoE) Notification: Wednesday, 14 July, 2021 Workshop: Sunday, 22 August, 2021 The 13th Haskell Implementors' Workshop is to be held alongside ICFP 2021 this year virtually. 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 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 short 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 2021. 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 encouraged to attend the workshop -- we need your feedback to keep the Haskell ecosystem thriving. Students working with Haskell are specially 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, optimisation 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 should be made via HotCRP. The website is: https://icfp-hiw21.hotcrp.com/ We will also have lightning talks session. These have been very well received in recent years, and we aim to increase the time available to them. Lightning talks 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. Logistics --------- Due to the on-going COVID-19 situation, ICFP (and, consequently, HIW) will be held remotely this year. However, the organizers are still working hard to provide for a great workshop experience. While we are sad that this year will lack the robust hallway track that is often the highlight of HIW, we believe that this remote workshop presents a unique opportunity to include more of the Haskell community in our discussion and explore new modes of communicating with our colleagues. We hope that you will join us in making this HIW as vibrant as any other. Program Committee ----------------- * Dominique Devriese (Vrije Universiteit Brussel) * Daan Leijen (Microsoft Research) * Andres Löh (Well-Typed LLP) * Julie Moronuki (Typeclass Consulting) * John Wiegley (DFINITY) * Ningning Xie (the University of Hong Kong) * Edward Z. Yang (Facebook AI Research) Contact ------- * Ningning Xie <xnning at hku.hk>

1 0

an issue tracker for better error messages
by Richard Eisenberg 13 May '21

13 May '21

Hi devs, I've just posted https://discourse.haskell.org/t/proposal-an-issue-tracker-for-better-error-… <https://discourse.haskell.org/t/proposal-an-issue-tracker-for-better-error-…>, a description of an idea to create an issue tracker dedicated only to error messages. My hope is that the tracker is used to boil issues users have with error messages down to a concrete suggestion for a wording change -- and that only when we have that concrete suggestion will a ticket be made on the GHC tracker. What do we think here of this idea? If you have a thought about the overall idea, I invite you to comment on Discourse; if you have a thought about GHC's response to this, this list seems like the best venue. Thanks, Richard

1 0