- ghc-devs - Haskell.org

GitLab upgrade soon
by Ben Gamari 19 Mar '21

19 Mar '21

Hi all, I will be performing a GitLab upgrade starting in approximately one hour. While I generally try to do this with more notice and out of working hours, in this case there is an exploitable GitLab vulnerability that deserves swift action. Thank you for you patience. Cheers, - Ben

2 2

Pull request to editline
by Oleg Grenrus 18 Mar '21

18 Mar '21

Hi Judah, I'm sending your an email, in case you haven't noticed GitHub notifications. I have a PR https://github.com/judah/haskeline/pull/153 (now opened for two months). It's blocking work on Data.List specialization. Also Ben have pinged you on https://github.com/judah/haskeline/issues/154 to make releases for 9.0.1 and 9.0.2. It would be very great if my patch could be merged and released, that should make editline ready for 9.2 and maybe even 9.4 (I think we are too late with refactor of Data.List for 9.2). - Oleg

2 2

Is referring to GHC-proposals in GHC user manual bad practice or not?
by Oleg Grenrus 17 Mar '21

17 Mar '21

I have a following question: My lexer rules related proposal was recently accepted. The biggest part of getting it in is writing documentation for it. While looking at Divergence from Haskell 98 and Haskell 2010 section of the user manual, in particular Lexical syntax, it already has See "GHC Proposal #229 for the precise rules.". Can I just the same? (I think there was an implicit acceptance of that practice in e.g. https://gitlab.haskell.org/ghc/ghc/-/merge_requests/1664#note_238759) However, I think that referring to proposals text for "essential" bits of information is a bad practice. Because GHC proposals are sometimes amended, one have to look into GitHub history to find out what were there for a particular time point of a GHC release. Very laborous. --- Currently there is 23 references to about a dozen of proposals. An example are passages like In 9.0, the behavior of this extension changed, and now we require that a negative literal must not be preceded by a closing token (see `GHC Proposal #229 <https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0229-w…>`__ for the definition of a closing token). or a future release will be turned off by default and then possibly removed. The reasons for this and the deprecation schedule are described in `GHC proposal #30 <https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0030-r…>`__. And there are better examples, which are references for more information, not essential one, like See the proposal `DuplicateRecordFields without ambiguous field access <https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0366-n…>`_ and the documentation on :extension:`DuplicateRecordFields` for further details. (I'd put the internal user manual link first), or But these automatic eta-expansions may silently change the semantics of the user's program, and deep skolemisation was removed from the language by `GHC Proposal #287 <https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0287-s…>`__. This proposal has many more examples. --- So to boil down my question, can I write Lexical syntax of identifiers and decimal numbers differs slightly from the Haskell report. See GHC Proposal #403 for the precise rules and differences. - Oleg

5 7

Generalising KnowNat/Char/Symbol?
by Sylvain Henry 16 Mar '21

16 Mar '21

Hi, I would like to have a KnownWord constraint to implement a type-safe efficient sum type. For now [1] I have: data V (vs :: [Type]) = Variant !Word Any where Word is a tag used as an index in the vs list and Any a value (unsafeCoerced to the appropriate type). Instead I would like to have something like: data V (vs :: [Type]) = Variant (forall w. KnownWord w => Proxy w -> Index w vs) Currently if I use KnownNat (instead of the proposed KnownWord), the code isn't very good because Natural equality is implemented using `naturalEq` which isn't inlined and we end up with sequences of comparisons instead of single case-expressions with unboxed literal alternatives. I could probably implement KnownWord and the required stuff (axioms and whatnot), but then someone will want KnownInt and so on. So would it instead make sense to generalise the different "Known*" we currently have with: class KnownValue t (v :: t) where valueSing :: SValue t v newtype SValue t (v :: t) = SValue t litVal :: KnownValue t v => proxy v -> t type KnownNat = KnownValue Natural type KnownChar = KnownValue Char type KnownSymbol = KnownValue String type KnownWord = KnownValue Word Thoughts? Sylvain [1] https://hackage.haskell.org/package/haskus-utils-variant-3.1/docs/Haskus-Ut…

3 2

Build failure -- missing dependency? Help!
by Simon Peyton Jones 16 Mar '21

16 Mar '21

I'm getting this (with 'sh validate -legacy'). Oddly * It does not happen on HEAD * It does happen on wip/T19495, a tiny patch with one innocuous change to GHC.Tc.Gen.HsType I can't see how my patch could possible cause "missing files" in ghc-bignum! I'm guessing that there is a missing dependency that someone doesn't show up in master, but does in my branch, randomly. There's something funny about ghc-bignum; it doesn't seem to be a regular library Can anyone help? Thanks Simon "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O -H64m -Wall -fllvm-fill-undef-with-garbage -Werror -this-unit-id base-4.16.0.0 -hide-all-packages -package-env - -i -ilibraries/base/. -ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/./autogen -Ilibraries/base/dist-install/build/./autogen -Ilibraries/base/include -Ilibraries/base/dist-install/build/include -optP-include -optPlibraries/base/dist-install/build/./autogen/cabal_macros.h -package-id ghc-bignum-1.0 -package-id ghc-prim-0.8.0 -package-id rts -this-unit-id base -Wcompat -Wnoncanonical-monad-instances -XHaskell2010 -O -dcore-lint -ticky -Wwarn -no-user-package-db -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags -Wnoncanonical-monad-instances -outputdir libraries/base/dist-install/build -dynamic-too -c libraries/base/./GHC/Exception/Type.hs-boot -o libraries/base/dist-install/build/GHC/Exception/Type.o-boot -dyno libraries/base/dist-install/build/GHC/Exception/Type.dyn_o-boot Failed to load interface for 'GHC.Num.Integer' There are files missing in the 'ghc-bignum' package, try running 'ghc-pkg check'. Use -v (or `:set -v` in ghci) to see a list of the files searched for. make[1]: *** [libraries/base/ghc.mk:4: libraries/base/dist-install/build/GHC/Exception/Type.o-boot] Error 1 make[1]: *** Waiting for unfinished jobs....

4 7

GSOC Idea: Bytecode serialization and/or Fat Interface files
by Zubin Duggal 14 Mar '21

14 Mar '21

Hi all, This is following up on this recent discussion on the list concerning fat interface files: https://mail.haskell.org/pipermail/ghc-devs/2020-October/019324.html Now that we have been accepted as a GSOC organisation, I think it would be a good project idea for a sufficiently motivated and advanced student. This is a call for mentors (and students as well!) who would be interested in this project The problem is the following: Haskell Language Server (and ghci with `-fno-code`) have very fast startup times for codebases which don't make use of Template Haskell, and thus don't require any code-gen to typecheck. This is because they can simply read the cached iface files generated by a previous compile and don't need to re-invoke the typechecker. However, as soon as TH is involved, we are forced to retypecheck and compile files, since it is not possible to restart the code-gen process starting with only a iface file. I can think of two ways to address this problem: 1. Allow bytecode to be serialized 2. Serialize desugared Core into iface files (fat interfaces), so that (byte)code-gen can be restarted from this point and doesn't need (1) might be challenging, but offers a few more advantages over (2), in that we can reduce the work done to load TH-heavy codebases to just a load of the cached bytecode objects from disk, and could make the load process (and times) for these codebases directly comparable to their TH-free cousins. It would also make ghci startup a lot faster with a warm cache of bytecode objects, bringing ghci startup times in line with those of -fno-code However (2) might be much easier to achieve and offers many of the same advantages, in that we would not need to re-run the compiler frontend or core-to-core optimisation phases. There is also already a (slightly bitrotted) implementation of (2) thanks to the work of Edward Yang. If any of this sounds exciting to you as a student or a mentor, please get in touch. In particular, I think (2) is a feasible project that can be completed with minimal mentoring effort. However, I'm only vaguely familiar with the details of the byte code generator, so if (1) is a direction we want to pursue, we would need a mentor familiar with the details of this part of GHC. Cheers, Zubin

5 5

GHC Exactprint merge process
by Alan & Kim Zimmerman 12 Mar '21

12 Mar '21

I have been running a branch in !2418[1] for just over a year to migrate the ghc-exactprint functionality directly into the GHC AST[2], and I am now satisfied that it is able to provide all the same functionality as the original. This is one of the features intended for the impending 9.2.1 release, and it needs to be reviewed to be able to land. But the change is huge, as it mechanically affects most files that interact with the GHC AST. So I have split out a precursor !5158 [3] with just the new types that are used to represent the annotations, so it can be a focal point for discussion. It is ready for review, please comment if you have time and interest. Regards Alan [1] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/2418 [2] https://gitlab.haskell.org/ghc/ghc/-/issues/17638 [3] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5158

3 4

Inlining of `any @[]` vs `elem @[]`
by ÉRDI Gergő 12 Mar '21

12 Mar '21

Hi, The inlining behaviour of `any @[]` and `elem @[]` differs in a way that I am not sure is intentional, and it is affecting Clash (see https://github.com/clash-lang/clash-compiler/issues/1691) I would think that if it is a good idea to inline `any` then inlining `elem` would be just as good an idea, or vice versa. However, `any` is defined polymorphically over `Foldable`, via `foldMap` using `foldr`, with all steps between (and `foldr @[]`!) marked as `INLINE`. The result is that if you use `any (x ==) [1, 5, 7]` you get the following beautiful Core: ``` topEntity = \ (x_agAF :: Int) -> case x_agAF of { GHC.Types.I# y_ahao -> case y_ahao of { __DEFAULT -> GHC.Types.False; 1# -> GHC.Types.True; 5# -> GHC.Types.True; 7# -> GHC.Types.True } } ``` As the kids these days would say: *chef's kiss*. `elem`, on the other hand, is a typeclass method of `Foldable`, with a default implementation in terms of `any`, but overridden for lists with the following implementation: ``` GHC.List.elem :: (Eq a) => a -> [a] -> Bool GHC.List.elem _ [] = False GHC.List.elem x (y:ys) = x==y || GHC.List.elem x ys {-# NOINLINE [1] elem #-} {-# RULES "elem/build" forall x (g :: forall b . Eq a => (a -> b -> b) -> b -> b) . elem x (build g) = g (\ y r -> (x == y) || r) False #-} ``` This is marked as non-inlineable until phase 1 (so that `elem/build` has a chance of firing), but it seems that when build fusion doesn't apply (since `[1, 5, 7]` is, of course, not built via `build`), no inlining happens AT ALL, even in later phases, so we end up with this: ``` topEntity = \ (x_agAF :: Int) -> GHC.List.elem @ Int GHC.Classes.$fEqInt x_agAF (GHC.Types.: @ Int (GHC.Types.I# 1#) (GHC.Types.: @ Int (GHC.Types.I# 5#) (GHC.Types.: @ Int (GHC.Types.I# 7#) (GHC.Types.[] @ Int)))) ``` So not only does it trip up Clash, it would also result in less efficient code in software when using "normal" GHC. Is this all intentional? Wouldn't it make more sense to mark `GHC.List.elem` as `INLINE [1]` instead of `NOINLINE [1]`, so that any calls remaining after build fusion would be inlined? Thanks, Gergo

2 6

Re: WSL2
by Tom Ellis 12 Mar '21

12 Mar '21

SPJ Wrote: > I've just installed WSL2 and built GHC. I get this (single) > validation failure in libraries/unix/tests/getGroupEntryForName. It > seems to be just an error message wibble, but I can't push a change > to master because that'll affect everyone else. Interesting, I've only ever built GHC on WSL and WSL2. I've seen this error message on WSL2 during every test run, I think. I didn't realise that it never occurred on other platforms, let alone that it was WSL2 specific! Tom

4 11

What type of performance regression testing does GHC go through?
by Tom Ellis 12 Mar '21

12 Mar '21

A user posted the following to the ghc-proposals repository. Both JB and RAE suggested ghc-devs as a more appropriate forum. Since I have no idea whether the user has even ever used a mailing list before I thought I would lower the activation energy by posting their message for them. https://github.com/ghc-proposals/ghc-proposals/issues/410 > Hi, > > Does the GHC release or development process include regression > testing for performance? > > Is this the place to discuss ideas for implementing such a thing and > to eventually craft a proposal? > > I believe the performance impact of changes to GHC needs to be > verified/validated before release. I also believe this would be > feasible if we tracked metrics on building a wide variety of > real-world packages. Using real-world packages is one of the best > ways to see the actual impact users will experience. It's also a > great way to broaden the scope of tests, particularly with the > combination of language pragmas and enabled features within the > compiler.

2 1