- ghc-devs - Haskell.org

linting GHC
by Richard Eisenberg 01 May '21

01 May '21

Hi devs, I see in CI that we're now linting the GHC source code. In order to avoid CI failure, I would like to lint locally, and I somehow know (though I forget where I learned it) that hadrian/build lint:compiler is the way to do this. After building hlint, I am able to do this. But the output is surprising; here is the tail: # hlint (for lint:compiler) compiler/GHC/Tc/Utils/Unify.hs:2:1-36: Warning: Unused LANGUAGE pragma Found: {-# LANGUAGE MultiWayIf #-} Perhaps you should remove it. compiler/stage1/build/GHC/Parser.hs:6:1-29: Warning: Unused LANGUAGE pragma Found: {-# LANGUAGE ViewPatterns #-} Perhaps you should remove it. compiler/stage1/build/GHC/Parser.hs:8:1-27: Warning: Unused LANGUAGE pragma Found: {-# LANGUAGE LambdaCase #-} Perhaps you should remove it. compiler/stage1/build/GHC/Parser.hs:38:1-54: Warning: Use fewer imports Found: import Control.Monad ( unless, liftM, when, (<=<) ) import Control.Monad ( ap ) Perhaps: import Control.Monad ( unless, liftM, when, (<=<), ap ) compiler/stage1/build/GHC/Parser.hs:43:1-18: Warning: Use fewer imports Found: import GHC.Prelude import GHC.Prelude Perhaps: import GHC.Prelude compiler/stage1/build/GHC/Cmm/Parser.hs:17:1-24: Warning: Use fewer imports Found: import GHC.StgToCmm.Prof import GHC.StgToCmm.Prof Perhaps: import GHC.StgToCmm.Prof compiler/stage1/build/GHC/Cmm/Parser.hs:71:1-20: Warning: Use fewer imports Found: import Control.Monad import Control.Monad ( ap ) Perhaps: import Control.Monad compiler/stage2/build/GHC/Parser.hs:6:1-29: Warning: Unused LANGUAGE pragma Found: {-# LANGUAGE ViewPatterns #-} Perhaps you should remove it. compiler/stage2/build/GHC/Parser.hs:8:1-27: Warning: Unused LANGUAGE pragma Found: {-# LANGUAGE LambdaCase #-} Perhaps you should remove it. compiler/stage2/build/GHC/Parser.hs:38:1-54: Warning: Use fewer imports Found: import Control.Monad ( unless, liftM, when, (<=<) ) import Control.Monad ( ap ) Perhaps: import Control.Monad ( unless, liftM, when, (<=<), ap ) compiler/stage2/build/GHC/Parser.hs:43:1-18: Warning: Use fewer imports Found: import GHC.Prelude import GHC.Prelude Perhaps: import GHC.Prelude compiler/stage2/build/GHC/Cmm/Parser.hs:17:1-24: Warning: Use fewer imports Found: import GHC.StgToCmm.Prof import GHC.StgToCmm.Prof Perhaps: import GHC.StgToCmm.Prof compiler/stage2/build/GHC/Cmm/Parser.hs:71:1-20: Warning: Use fewer imports Found: import Control.Monad import Control.Monad ( ap ) Perhaps: import Control.Monad 13 hints Error when running Shake build system: at want, called at src/Main.hs:104:30 in main:Main * Depends on: lint:compiler at cmd_, called at src/Rules/Lint.hs:70:3 in main:Rules.Lint * Raised the exception: Development.Shake.cmd, system command failed Command line: hlint -j --cpp-define x86_64_HOST_ARCH --cpp-include=includes --cpp-include=_build/stage1/lib --cpp-include=compiler --cpp-include=_build/stage1/lib/ghcplatform.h --cpp-include=_build/stage1/compiler/build -h compiler/.hlint.yaml compiler Exit code: 1 Stderr: There are several curiosities here: * I introduced one of these errors, in GHC.Tc.Utils.Unify; the other errors are in files I have not modified. Will these affect CI? * Hadrian crashes at the end. Is that expected? It says "system command failed" with a bunch of gobbledegook. Is this an error within Hadrian? Or is this just Hadrian's way of saying that it encountered an error when linting? If it's the latter, the current message is hard to read. * As you may be able to see, I use a dark-background terminal window. The colors output by the hlint process are nigh impossible to read when describing redundant LANGUAGE pragmas. Are these colors configurable? Thanks! Richard

2 1

Compiling libraries
by Simon Peyton Jones 30 Apr '21

30 Apr '21

Ben and other friends What is the approved way to build libraries with (and for) a compiler that I've just built? I tried this: bash$ cabal v2-install --with-ghc=/home/simonpj/code/ghc-9.2-branch/inplace/bin/ghc-stage2 streamly --allow-newer but it failed with Data/Primitive/Types.hs:273:844: error: * Couldn't match expected type 'Word#' with actual type 'Word8#' * In the fourth argument of 'shimmedSetWord8Array#', namely 'x#' (This was for a compiler built from the ghc-9.2 branch.) I'd like to be able to do the same for HEAD. I need to do this to help with the numerous tickets asking about library regressions. For example, I want to be able repoduce @harendra's example<https://gitlab.haskell.org/ghc/ghc/-/issues/19557#note_348969>, but I can't because I can't build streamly. Thanks! Simon

4 4

[ANNOUNCE] Experimental Windows GHC 8.10.5 binary release. Supports Haskell DLLs.
by kyra 29 Apr '21

29 Apr '21

An experimental Windows GHC 8.10.5 64-bit Visual C/Native Windows SDK binary compatible distribution is released. Features: Supports Haskell DLLs. Both static and dynamic compilers are shipped. Uses LLVM tools exclusively, hence linking is blazing fast compared to the stock distro. Is position-independent (can be loaded to any address, not only the lower 2GBs) and generates position-independent code. Based on and targets Microsoft Visual C runtime and native Windows SDK. The "full" variant of distro contains 438 extra prebuilt packages and a set utilities, including not only the mandatory cabal, stack, Happy and Alex, but also linters, formatters, preprocessors, and even beasts like pandoc, haskell-language-server and even Agda compiler. Distribution site: https://awson.github.io/ghc-nw/. Cheers, K. Briantsev (aka awson)

1 0

simple Haskell help needed on #19746
by Richard Eisenberg 28 Apr '21

28 Apr '21

Hi devs, tl;dr: Is there any (efficient) way to get the String consumed by a `reads`? I'm stuck in thinking about a fix for #19746. Happily, the problem is simple enough that I could assign it in the first few weeks of a Haskell course... and yet I can't find a good solution! So I pose it here for inspiration. The high-level problem: Assign correct source spans to options within a OPTIONS_GHC pragma. Current approach: The payload of an OPTIONS_GHC pragma gets turned into a String and then processed by GHC.Utils.Misc.toArgs :: String -> Either String [String]. The result of toArgs is either an error string (the Left result) or a list of lexed options (the Right result). A little-known fact is that Haskell strings can be put in a OPTIONS_GHC pragma. So I can write both {-# OPTIONS_GHC -funbox-strict-fields #-} and {-# OPTIONS_GHC "-funbox-strict-fieds" #-}. Even stranger, I can write {-# OPTIONS_GHC ["-funbox-strict-fields"] #-}, where GHC will understand a list of strings. While I don't really understand the motivation for this last feature (I posted #19750 about this), the middle option, with the quotes, seems like it might be useful. Desired approach: change toArgs to have this type: RealSrcLoc -> String -> Either String [Located String], where the input RealSrcLoc is the location of the first character of the input String. Then, as toArgs processes the input, it advances the RealSrcLoc (with advanceSrcLoc), allowing us to create correct SrcSpans for each String. Annoying fact: Not all characters advance the source location by one character. Tabs and newlines don't. Perhaps some other characters don't, too. Central stumbling block: toArgs uses `reads` to parse strings. This makes great sense, because `reads` already knows how to convert Haskell String syntax into a proper String. The problem is that we have no idea what characters were consumed by `reads`. And, short of looking at the length of the remainder string in `reads` and comparing it to the length of the input string, there seems to be no way to recreate this lost information. Note that comparing lengths is slow, because we're dealing with Strings here. Once we know what was consumed by `reads`, then we can just repeatedly call advancedSrcLoc, and away we go. Ideas to get unblocked: 1. Just do the slow (quadratic in the number of options) thing, looking at the lengths of strings often. 2. Reimplement reading of strings to return both the result and the characters consumed 3. Incorporate the parsing of OPTIONS_GHC right into the lexer It boggles me that there isn't a better solution here. Do you see one? Thanks, Richard

3 4

External STG Interpreter blog post
by Csaba Hruska 27 Apr '21

27 Apr '21

Hello, I've written a blog post about GHC-WPC's external stg interpreter. https://www.patreon.com/posts/external-stg-49857800 Feedback is welcome. Cheers, Csaba

3 4

magicDict
by Simon Peyton Jones 26 Apr '21

26 Apr '21

Ed, and other ghc-devs We are busy tidying up magicDict, and making it much more type-safe: see * https://gitlab.haskell.org/ghc/ghc/-/issues/16646 * https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5573 As part of that change we're think of changing its currently-rather-obscure name. I rather favour "reflectDict". Any other views? Simon

5 14

[ANNOUNCE] GHC 9.2.1-alpha2 released
by Ben Gamari 23 Apr '21

23 Apr '21

Hi all, The GHC developers are very happy to announce the availability of the second alpha release in the 9.2.1 series. Binary distributions, source distributions, and documentation are available at https://downloads.haskell.org/ghc/9.2.1-alpha2 GHC 9.2 will bring a number of exciting features including: * Many changes in the area of records, including the new `RecordDotSyntax` and `NoFieldSelectors` language extensions, as well as Support for `DuplicateRecordFields` with `PatternSynonyms`. * Introduction of the new `GHC2021` language extension set, giving users convenient access to a larger set of language extensions which have been long considered stable. * Merge of `ghc-exactprint` into the GHC tree, providing infrastructure for source-to-source program rewriting out-of-the-box. * Introduction of a `BoxedRep` `RuntimeRep`, allowing for polymorphism over levity of boxed objects (#17526) * Implementation of the `UnliftedDataTypes` extension, allowing users to define types which do not admit lazy evaluation ([proposal]) * The new [-hi profiling] mechanism which provides significantly improved insight into thunk leaks. * Support for the `ghc-debug` out-of-process heap inspection library [ghc-debug] * Support for profiling of pinned objects with the cost-centre profiler (#7275) * Introduction of Haddock documentation support in TemplateHaskell (#5467) * Proper support for impredicative types in the form of Quick-Look impredicativity. * A native code generator backend for AArch64. This pre-release brings nearly 50 fixes relative to the first alpha, although the long-awaited ARM NCG backend hasn't quite landed yet. As always, do give this a try and open a [ticket] if you see anything amiss. Happy testing, - Ben [proposal]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0265-u… [-hi profiling]: https://well-typed.com/blog/2021/01/first-look-at-hi-profiling-mode/ [ghc-debug]: http://ghc.gitlab.haskell.org/ghc-debug/ [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new

1 0

Integrating more base Instances in the `stock` deriving strategy?
by Hécate 15 Apr '21

15 Apr '21

Hi folks! I would like to start a discussion (if it hasn't already been done) around the idea of integrating the various type-classes that Base offers, that are hidden behind language extensions, in the `stock` deriving strategy. I wasn't around when it was all implemented, but I've always lived with it in my code bases, and I'd like to know if there are deeper issues pertaining to their exclusion from the `stock` deriving strategy. Here is the link to the discussion ticket: https://gitlab.haskell.org/ghc/ghc/-/issues/19707 Cheers, and have a nice week! -- Hécate ✨ 🐦: @TechnoEmpress IRC: Uniaika WWW: https://glitchbra.in RUN: BSD

1 0

instance {Semigroup, Monoid} (Bag a) ?
by Richard Eisenberg 15 Apr '21

15 Apr '21

Hi devs, In the work on simplifying the error-message infrastructure (heavy lifting by Alfredo, in cc), I've been tempted (twice!) to add > instance Semigroup (Bag a) where > (<>) = unionBags > > instance Monoid (Bag a) where > mempty = emptyBag to GHC.Data.Bag. The downside to writing these is that users might be tempted to write e.g. mempty instead of emptyBag, while the latter gives more information to readers and induces less manual type inference (to a human reader). The upside is that it means Bags work well with Monoid-oriented functions, like foldMap. I favor adding them, and slipped them into !5509 (a big commit with lots of other stuff). Alfredo rightly wondered whether this decision deserved more scrutiny, and so I'm asking the question here. What do we think? Thanks, Richard

7 7

What's the modern way to apply a polymorphic function to a Dynamic value in GHC 8.8 and onwards?
by YueCompl 13 Apr '21

13 Apr '21

Dear Cafe and GHC devs, There used to be a "principled way with pattern match on the constructor": ```hs data Dynamic where Dynamic :: Typeable a => a -> Dynamic apD :: Typeable f => (forall a. a -> f a) -> Dynamic -> Dynamic apD f (Dynamic a) = Dynamic $ f a ``` Source: https://www.reddit.com/r/haskell/comments/2kdcca/q_how_to_apply_a_polymorph… But now with GHC 8.8 as in my case, `Dynamic` constructor has changed its signature to: ```hs Dynamic :: forall a. TypeRep a -> a -> Dynamic ``` Which renders the `apD` not working anymore. And it seems missing dependencies now for an older solution Edward KMETT provides: ```hs apD :: forall f. Typeable1 f => (forall a. a -> f a) -> Dynamic -> Dynamic apD f a = dynApp df a where t = dynTypeRep a df = reify (mkFunTy t (typeOf1 (undefined :: f ()) `mkAppTy` t)) $ \(_ :: Proxy s) -> toDyn (WithRep f :: WithRep s (() -> f ())) ``` Source: https://stackoverflow.com/questions/10889682/how-to-apply-a-polymorphic-fun… So, how can I do that nowadays? Thanks, Compl

4 9