- ghc-devs - Haskell.org

ZuriHac 2021 - GHC Track - Call for Contributions
by Andreas Herrmann 11 May '21

11 May '21

Dear GHC developers, This year's ZuriHac 2021 [1], online Friday 18th June to Sunday 20th June, will again feature a dedicated GHC track to foster contributions to GHC and teach newcomers how to participate in GHC's development. For that we need your help: We would like to invite you to organize a session in the GHC track. This could be in form of a presentation, a workshop, or a hack session with topics centered around GHC. For some inspiration, these are the subjects from last year's track: - Write a GHC extension in 30 minutes, by Richard Eisenberg - A tour of linear types and linear base, by Divesh Otwani - QualifiedDo: customizable 'do' syntax without fuss, by Facundo Dominguez - On "simple" constraints for typechecker plugins, by Nicolas Frisby Please let us know if you'd be interested in leading a session or a workshop. You can contact either Niklas or myself, on this list or by private message. Best, Andreas and Niklas ZuriHac 2021 GHC track coordinators [1]: https://zfoh.ch/zurihac2021/

2 2

Warnings
by Simon Peyton Jones 04 May '21

04 May '21

If 'transformers' purposely has orphan instances, shouldn't we switch off the warnings about them? Simon "/opt/ghc/bin/ghc" -hisuf hi -osuf o -hcsuf hc -static -O -H64m -Wall -package-db libraries/bootstrapping.conf -this-unit-id transformers-0.5.6.2 -hide-all-packages -package-env - -i -ilibraries/transformers/. -ilibraries/transformers/dist-boot/build -Ilibraries/transformers/dist-boot/build -ilibraries/transformers/dist-boot/build/./autogen -Ilibraries/transformers/dist-boot/build/./autogen -Ilibraries/transformers/. -optP-include -optPlibraries/transformers/dist-boot/build/./autogen/cabal_macros.h -package-id base-4.14.1.0 -XHaskell98 -no-user-package-db -rtsopts -fno-warn-unused-matches -fno-warn-unused-imports -fno-warn-deprecated-flags -outputdir libraries/transformers/dist-boot/build -c libraries/transformers/./Control/Applicative/Lift.hs -o libraries/transformers/dist-boot/build/Control/Applicative/Lift.o libraries/transformers/Control/Monad/Trans/Error.hs:98:1: warning: [-Worphans] Orphan instance: instance [safe] Error e => Alternative (Either e) To avoid this move the instance declaration to the module of the class or of the type, or wrap the type with a newtype and declare the instance on the new type. | 98 | instance (Error e) => Alternative (Either e) where | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^... libraries/transformers/Control/Monad/Trans/Error.hs:103:1: warning: [-Worphans] Orphan instance: instance [safe] Error e => MonadPlus (Either e) To avoid this move the instance declaration to the module of the class or of the type, or wrap the type with a newtype and declare the instance on the new type. | 103 | instance (Error e) => MonadPlus (Either e) where | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^...

2 1

structured error messages
by Richard Eisenberg 03 May '21

03 May '21

Hi all, Alfredo and I are hard at work redesigning GHC's error-message system. It is time for more input, though, from clients of the system -- those writing IDEs and other tooling on top of GHC. The key question: How would you like your errors served? Right now, errors are served well-done: fully cooked into structureless strings that can be easily given to users. The problem with this is that IDEs cannot easily intervene between GHC and the users, as all the nutrition (that is, detailed information) has been cooked away. The new design allows for *structured errors*, where error messages are represented by elements of some error type. Different messages have different constructors of this type, and these constructors can carry auxiliary information. GHC will store these errors raw and cook them (that is, turn them into readable strings) only right before printing them. If the raw messages were somehow passed to IDEs, then IDEs could handle them non-uniformly. (For example, if a module name and a file name are different, the IDE could just present a dialog to the user asking whether the user would like to change one automatically.) There are a few open questions: * In what vessel shall the raw messages be served? In other words, how do IDEs expect to interact with this new system? - One route would be to pass e.g. -fjson-errors, which means that GHC presents the raw messages in a JSON format, for IDEs to parse. That's OK, but it still means that IDEs would have to have their own raw error message types to parse into. - Another route would be for the IDE to link against GHC itself, and then invoke the compiler via a function call that returns the raw messages directly. - Another route is some kind of middle ground, where the IDE passes e.g. -fbinary-errors=<filename> instructing GHC to write out a binary encoding of its messages to some file (or pipe, I suppose). These could then be deserialized back into GHC's own error types, but running in a separate process (linked against GHC, once again). - I'm sure you can come up with other interaction strategies. * What will an IDE do with these messages? It might have special handling for some, but GHC has a lot of different messages, and I imagine IDEs will want many just to be printed to the user. If an IDE has only the raw message, then the IDE is forced to do all the cooking -- no good. So there must be a way to take a raw message and render it into a user-readable string. - Maybe the above methods produce both the raw error and the rendered one? Then the IDE can choose which it prefers to use. - GHC could easily export its pretty-printing functions that take in the raw messages and produce rendered ones. But that (again) requires linking against GHC. Note that we are not (here, yet) discussing errors served at points between raw and well-done, though I would like to do so. Such an error would be rendered into a format where textual bits are interleaved with more structured bits, which would enable e.g. clicking on expressions within error messages to get their types. That (important feature) comes separately. So: what do consumers want here? Preview: You can take a look at some raw error messages from the driver in https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5533 <https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5533>. Thanks! Richard

3 3

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 29 Apr '21

29 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 22 Apr '21

22 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