- ghc-devs - Haskell.org

Using GHC Core as a Language Target
by Ara Adkins 29 Oct '18

29 Oct '18

Hey All, I was chatting to SPJ about the possibility of using GHC Core + the rest of the GHC compilation pipeline as a target for a functional language, and he mentioned that asking here would likely be more productive when it comes to the GHC API. I'm wondering where the best place would be for me to look in the API for building core expressions, and also whether it is possible to trigger the GHC code-generation pipeline from the core stage onwards. Best, Ara

3 4

CI status
by Ben Gamari 29 Oct '18

29 Oct '18

Hi everyone, As you likely have noticed, GHC's CI is a bit of a mess since the Hadrian merge, especially for differentials based on commits prior to the merge. The problem is a tiresome limitation of Harbormaster's CI strategy [1]. I have taken this opportunity to finally move testing of Differentials to CircleCI. Unfortunately this has taken longer than anticipated due to more tiresome Phabricator issues. At the moment the only guidance I can offer for those in need of CI is to sit tight; the problem is being worked on. Cheers, - Ben [1] Namely, Harbormaster attempts to reuse working trees to perform builds. However, it fails to remove stale submodules, meaning any attempt to checkout a post-Hadrian-merge commit fails.

1 0

Treatment of unknown pragmas
by Ben Gamari 28 Oct '18

28 Oct '18

Hi everyone, Recently Neil Mitchell opened a pull request [1] proposing a single-line change: Adding `{-# HLINT ... #-}` to the list of pragmas ignored by the lexer. I'm a bit skeptical of this idea. Afterall, adding cases to the lexer for every tool that wants a pragma seems quite unsustainable. On the other hand, a reasonable counter-argument could be made on the basis of the Haskell Report, which specifically says that implementations should ignore unrecognized pragmas. If GHC did this (instead of warning, as it now does) then this wouldn't be a problem. Of course, silently ignoring mis-typed pragmas sounds terrible from a usability perspective. For this reason I proposed that the following happen: * The `{-# ... #-}` syntax be reserved in particular for compilers (it largely already is; the Report defines it as "compiler pragma" syntax). The next Report should also allow implementations to warn in the case of unrecognized pragmas. * We introduce a "tool pragma" convention (perhaps even standardized in the next Report). For this we can follow the model of Liquid Haskell: `{-@ $TOOL_NAME ... @-}`. Does this sound sensible? Cheers, - Ben [1] https://github.com/ghc/ghc/pull/204

14 36

[ANNOUNCE] GHC 8.4.4 released
by Ben Gamari 27 Oct '18

27 Oct '18

Hello everyone, The GHC team is pleased to announce the availability of GHC 8.4.4, a patch-level release in the 8.4 series. The source distribution, binary distributions, and documentation for this release are available at https://downloads.haskell.org/~ghc/8.4.4 This release fixes several bugs present in 8.4.3 These include, - A bug which could result in memory unsafety with certain uses of `touch#` has been resolved. (#14346) - A compiler panic triggered by some GADT record updates has been fixed (#15499) - The `text` library has been updated, fixing several serious bugs in the version shipped with GHC 8.4.3 (see `text` issues #227, #221, and #197. - A serious code generation bug in the LLVM code generation, potentially resulting in incorrect evaluation of floating point expressions, has been fixed (#14251) As always, the full release notes can be found in the users guide, https://downloads.haskell.org/~ghc/8.4.4/docs/html/users_guide/8.4.4-notes.… Thanks to everyone who has contributed to developing, documenting, and testing this release! As always, let us know if you encounter trouble. How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: https://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating efficient code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces. GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page https://www.haskell.org/ghc/ GHC developers' home page https://ghc.haskell.org/trac/ghc/ Haskell home page https://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: https://ghc.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: https://ghc.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: https://ghc.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at https://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see https://mail.haskell.org/cgi-bin/mailman/listinfo Some GHC developers hang out on #haskell on IRC, too: https://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here:

7 9

can't get docs / sphinx building for ghc 8.4.4
by Carter Schonwald 26 Oct '18

26 Oct '18

hello all, i'm getting the following error quite consistently on OSX, for getting the docs working / built and its quite impossible to install if the docs aren't fully built i've bolded below an except how do i fix thisssss please help meeeee :) many thanks. *Extension error:* *The 'ghc-flag' directive is already registered to domain std* *docs/users_guide/ghc.mk:16 <http://ghc.mk:16>: recipe for target 'docs/users_guide/users_guide.pdf' failed* *make[1]: *** [docs/users_guide/users_guide.pdf] Error 2* *make[1]: *** Waiting for unfinished jobs....* *Extension error:* *The 'ghc-flag' directive is already registered to domain std* *Extension error:* *The 'ghc-flag' directive is already registered to domain std* *docs/users_guide/ghc.mk:28 <http://ghc.mk:28>: recipe for target 'docs/users_guide/build-man/ghc.1' failed* the full end of the build is as follows any /usr/local/bin/ginstall -c -m 755 utils/genapply/dist/build/tmp/genapply inplace/lib/bin/genapply cp libffi/build/inst/lib/libffi.a rts/dist/build/libCffi.a "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Wall -this-unit-id ghc-prim-0.5.2.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/./autogen -Ilibraries/ghc-prim/dist-install/build/./autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/./autogen/cabal_macros.h -package-id rts -this-unit-id ghc-prim -XHaskell2010 -O2 -no-user-package-db -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags -Wnoncanonical-monad-instances -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -dynamic-too -c libraries/ghc-prim/./GHC/Tuple.hs -o libraries/ghc-prim/dist-install/build/GHC/Tuple.o -dyno libraries/ghc-prim/dist-install/build/GHC/Tuple.dyn_o Running Sphinx v1.8.1 Running Sphinx v1.8.1 Running Sphinx v1.8.1 loading pickled environment... done building [mo]: targets for 0 po files that are out of date building [html]: targets for 4 source files that are out of date updating environment: 0 added, 0 changed, 0 removed looking for now-outdated files... none found pickling environment... done preparing documents... done writing output... [ 25%] index Extension error: The 'ghc-flag' directive is already registered to domain std docs/users_guide/ghc.mk:16: recipe for target 'docs/users_guide/users_guide.pdf' failed make[1]: *** [docs/users_guide/users_guide.pdf] Error 2 make[1]: *** Waiting for unfinished jobs.... Extension error: The 'ghc-flag' directive is already registered to domain std Extension error: The 'ghc-flag' directive is already registered to domain std docs/users_guide/ghc.mk:28: recipe for target 'docs/users_guide/build-man/ghc.1' failed make[1]: *** [docs/users_guide/build-man/ghc.1] Error 2 docs/users_guide/ghc.mk:16: recipe for target 'docs/users_guide/build-html/users_guide/index.html' failed make[1]: *** [docs/users_guide/build-html/users_guide/index.html] Error 2 writing output... [100%] markup /Users/carter/dev-checkouts/ghc-tree/ghc-8.4.4-checkout-clang-build/utils/haddock/doc/invoking.rst:457: WARNING: unknown option: -cpp generating indices... genindex writing additional pages... search copying static files... done copying extra files... done dumping search index in English (code: en) ... done dumping object inventory... done build succeeded, 1 warning. The HTML pages are in .build-html. cp -R utils/haddock/doc/.build-html utils/haddock/doc/haddock Makefile:122: recipe for target 'all' failed make: *** [all] Error 2

1 0

Re: Suppressing False Incomplete Pattern Matching Warnings for Polymorphic Pattern Synonyms
by Ryan Scott 25 Oct '18

25 Oct '18

The fact that `LL` can't be used in a COMPLETE pragma is a consequence of its current design. Per the users' guide [1]: To make things more formal, when the pattern-match checker requests a set of constructors for some data type constructor T, the checker returns: * The original set of data constructors for T * Any COMPLETE sets of type T Note the use of the phrase *type constructor*. The return type of all constructor-like things in a COMPLETE set must all be headed by the same type constructor T. Since `LL`'s return type is simply a type variable `a`, this simply doesn't work with the design of COMPLETE sets. But to be perfectly honest, I feel that trying to put `LL` into a COMPLETE set is like putting a square peg into a round hole. The original motivation for COMPLETE sets, as given in this wiki page [2], is to support using pattern synonyms in an abstract matter—that is, to ensure that users who match on pattern synonyms don't have any internal implementation details of those pattern synonyms leak into error messages. This is well and good for many use cases, but there are also many use cases where we don't *care* about abstraction. Sometimes, we simply define a pattern synonym to be a convenient shorthand for a complicated pattern to facilitate code reuse, and nothing more. `LL` is a perfect example of this, in my opinion. `LL` is simply a thin wrapper around the use of `decomposeSrcSpan` as a view pattern. Trying to put `LL` into a COMPLETE set is silly since our intention isn't to hide the implementation details of decomposing a `SrcSpan`, but rather to avoid the need to copy-paste `(decomposeSrcSpan -> (m , s))` in a bazillion patterns. Correspondingly, any use of `LL` ought to be treated as if the `(decomposeSrcSpan -> (m , s))` pattern were inlined—and from the pattern-match coverage checker's point of view, that *is* exhaustive! What's the moral of the story here? To me, this is a sign that the design space of pattern synonym coverage checking isn't rich enough. In addition to the existing {-# COMPLETE #-} machinery that we have today, I think we need to have a separate pragma for pattern synonyms that are intended to be transparent, non-abstract wrappers around patterns ({-# TRANSPARENT #-}, perhaps). Ryan S. ----- [1] https://downloads.haskell.org/~ghc/8.6.1/docs/html/users_guide/glasgow_exts… [2] https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms/CompleteSigs

3 2

Suppressing False Incomplete Pattern Matching Warnings for Polymorphic Pattern Synonyms
by Shayan Najd 25 Oct '18

25 Oct '18

Dear GHC hackers, On our work on the new front-end AST for GHC [0] based on TTG [1], we would like to use a pattern synonym like the following [2]: {{{ pattern LL :: HasSrcSpan a => SrcSpan -> SrcSpanLess a -> a pattern LL s m <- (decomposeSrcSpan -> (m , s)) where LL s m = composeSrcSpan (m , s) }}} We know that any match on `LL` patterns, makes the pattern matching total, as it uses a view pattern with a total output pattern (i.e., in `decomposeSrcSpan -> (m , s)`, the pattern `(m , s)` is total). As far as I understand, currently COMPLETE pragmas cannot be used with such a polymorphic pattern. What do you suggest us to do to avoid the false incomplete pattern matching warnings? Thanks, Shayan [0] https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow [1] https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/TreesThatGr… [2] https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/HandlingSou…

2 1

Shall we make -dsuppress-uniques default?
by Ömer Sinan Ağacan 24 Oct '18

24 Oct '18

I asked this on IRC and didn't hear a lot of opposition, so as the next step I'd like to ask ghc-devs. I literally never need the details on uniques that we currently print by default. I either don't care about variables too much (when not comparing the output with some other output), or I need -dsuppress-uniques (when comparing outputs). The problem is I have to remember to add -dsuppress-uniques if I'm going to compare the outputs, and if I decide to compare outputs after the fact I need to re-generate them with -dsuppress-uniques. This takes time and effort. If you're also of the same opinion I suggest making -dsuppress-uniques default, and providing a -dno-suppress-uniques (if it doesn't already exist). Ömer

4 4

Why align all pinned array payloads on 16 bytes?
by Ömer Sinan Ağacan 24 Oct '18

24 Oct '18

Hi, I just found out we currently align all pinned array payloads to 16 bytes and I'm wondering why. I don't see any comments/notes on this, and it's also not part of the primop documentation. We also have another primop for aligned allocation: newAlignedPinnedByteArray#. Given that alignment behavior of newPinnedByteArray# is not documented and we have another one for aligned allocation, perhaps we can remove alignment in newPinnedByteArray#. Does anyone remember what was the motivation for always aligning pinned arrays? Thanks Ömer

5 6

Hadrian has been merged!
by Ben Gamari 23 Oct '18

23 Oct '18

Hi everyone, Hadrian is now merged into the GHC tree. For better or worse, due to the large number of merge commits in the Hadrian repository we were unable to squash the early history of the project. If you encounter trouble using the Hadrian build system please file a ticket on Trac, setting the "Component" field to "Build System (Hadrian)". I have renamed the old "Build System" component in Trac's issue tracker to "Build System (make)" to avoid confusion. Hadrian tickets opened before the merge will remain on GitHub. Likewise, if you would like to contribute to Hadrian please do so via Phabricator. The remaining pull requests against the GitHub repository will be merged in due course but further requests will be redirected to Phabricator. Cheers, - Ben

1 0