March 2018 - ghc-devs

The Haskell Report: who maintains it?
by Simon Peyton Jones 15 Mar '18

15 Mar '18

Friends Does anyone know who, if anyone, feels responsible for committing updates to the Haskell 2010 Report? Who even has commit rights? There’s Frank’s pull request below, and I have another important typo to fix. Thanks Simon From: Frank Steffahn [mailto:notifications@github.com] Sent: 11 March 2018 17:03 To: haskell/haskell-report <haskell-report(a)noreply.github.com> Cc: Subscribed <subscribed(a)noreply.github.com> Subject: [haskell/haskell-report] Fix a typo in: Semantics of Case Expressions, Part 3 (s) (#4) Hi. I noticed this in the Haskell 2010 report, which is an obvious typo / mistake. I’m not 100% sure if this is the right branch (or even in general the right place) to note this, but I hope it will get fixed ;-) This seems like it is an artifact of copy-and-pasting from “Semantics of Case Expressions, Part 1 (c)” without properly adapting the thing, especially in commit bc94554<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com…>. ________________________________ You can view, comment on, or merge this pull request online at: https://github.com/haskell/haskell-report/pull/4<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com…> Commit Summary * Fix a typo in: Semantics of Case Expressions, Part 3 (s) File Changes * M report/exps.verb<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com…> (1) Patch Links: * https://github.com/haskell/haskell-report/pull/4.patch<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com…> * https://github.com/haskell/haskell-report/pull/4.diff<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com…> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com…>, or mute the thread<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com…>.

3 2

[ANNOUNCE] GHC 8.4.1 released
by Ben Gamari 14 Mar '18

14 Mar '18

The GHC developers are very happy to announce the 8.4.1 release of Glasgow Haskell Compiler. Binary and source distributions can be found at https://downloads.haskell.org/~ghc/8.4.1/ This is the third major release in the GHC 8 series. As such, the focus of this release is performance, stability, and consolidation. Consequently numerous cleanups can be seen throughout the compiler including, * Further refinement of TypeInType, including significant improvements in error messages. * Improvements in code generation resulting in noticable performance improvements in some types of programs. * Core library improvements, including phase 2 of the Semigroup/Monoid proposal * Many improvements to instance deriving * The resolution of nearly 300 other tickets A more thorough list of the changes in this release can be found in the release notes, https://downloads.haskell.org/~ghc/8.4.1/docs/html/users_guide/8.4.1-notes.… There are a few changes in release-engineering matters that should be noted, * This is GHC's first release on it's new, accelerated release schedule. From now on GHC will produce one release every six months. * While we typically strive to produce OpenBSD builds, the gcc shipped with OpenBSD 6.1 is unfortunately too old to compile this release. * FreeBSD builds are still in progress This release has been the result of approximately six months of work by over one hundred code contributors. Thanks to everyone who has helped in writing patches, testing, reporting bugs, and offering feedback over the last year. 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: http://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 http://www.haskell.org/ghc/ GHC developers' home page http://ghc.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: http://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: http://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: http://ghc.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users http://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: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug

5 7

Questions about pointers in GHC
by Xuanrui Qi 10 Mar '18

10 Mar '18

Hi all, I have a few questions about heap-allocated memory pointers in GHC. Both code and data live in the heap, and both can have pointers to other objects. However, according to my understanding, most heap-allocated objects would be immutable. Moreover even if objects might be mutated, most pointers should not be updated. I have heard that the runtime system might implement several features by updating pointers, but I am not sure which features are they. My question is thus: (1) is there a way to trace mutations of heap objects (for instance by modifying the GC system code) [I don't need to know what is the change, all I want to know is what has been changed], and (2) is there a way where I could trace pointer updates [in this case I'd like to know both the old and objects, preferably by name]? More specifically, are these possible by annotating/changing the runtime system only (i.e. not touching code generation)? Thanks, Ray Department of Computer Science Tufts University

3 2

NumericUnderscores extension was added to Cabal for ghc 8.6
by Takenobu Tani 09 Mar '18

09 Mar '18

Dear devs, The `NumericUnderscores` extension was added to Cabal for ghc 8.6. [1] I'm sending this mail referring to `BlockArguments`. [2] [1] https://github.com/haskell/cabal/pull/5130 [2] https://mail.haskell.org/pipermail/ghc-devs/2018-February/015341.html Regards, Takenobu

1 0

Re: [ANNOUNCE] GHC 8.4.1 released
by Ben Gamari 09 Mar '18

09 Mar '18

Vassil Ognyanov Keremidchiev <varosi(a)gmail.com> writes: > I saw there is ARM Aarch64 build, which is pretty cool! But will there be a > ARMv7 (32bit build) as well? > I do hope so. There have been a number of false-starts but hopefully the build that is currently running will finish. Unfortunately getting a working ARMv7 build is rather tricky due to a number of linker bugs that bite under various circumstances. Cheers, - Ben

1 0

Re: [ANNOUNCE] GHC 8.4.1 released
by Ben Gamari 08 Mar '18

08 Mar '18

Apostolos Syropoulos via Glasgow-haskell-users <glasgow-haskell-users(a)haskell.org> writes: > Hello, > > I tried to compile the latest bits on OpenIndiana (the open version of Solaris) and > compilation never starts because: > Can you try applying the attached patch? Cheers, - Ben

1 0

[ANNOUNCE] GHC 8.4.1-rc1 available
by Ben Gamari 07 Mar '18

07 Mar '18

The GHC development team is pleased to announce the first (and likely final) release candidate of GHC 8.4.1. The usual release artifacts are available from https://downloads.haskell.org/~ghc/8.4.1-rc1 This release will likely be the last release before the final 8.4.1 release, which, if things go well, will be released one week from today. Due to user demand we now offer a binary distribution for 64-bit Fedora 27, which links against ncurses6. This is in contrast to the Debian 8 distribution, which links against ncurses5. Users of newer distributions (Fedora 27, Debian Sid) should use this new Fedora 27 distribution. Also due to user demand we have reintroduced compatibility with GCC 4.4, which earlier alphas had dropped due to #14244. Note that this release candidate is still affected by #14705, although this will certainly be resolved before the final release is made. === Notes on release scheduling === The 8.4.1 release marks the first release where GHC will be adhering to its new, higher-cadence release schedule [1]. Under this new scheme, major releases will be made in 6-month intervals with interstitial minor releases as necessary. In order to minimize the likelihood of schedule slippage and to ensure adequate testing, each major release will be preceded by a number of regular alpha releases. We will begin issuing these releases roughly three months before the final date of the major release and will issue roughly one every two weeks during this period. This high release cadence will allow us to quickly get fixes into users' hands and more quickly identify potential issues. As always, do let us know if you encounter any trouble in the course of testing. Thanks for your help! Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/blog/2017-release-schedule

4 8

ghc, OpenBSD and stack pointer checking
by Matthias Kilian 06 Mar '18

06 Mar '18

Hi, while working on an ghc update for OpenBSD (to ghc-8.2.2), I tested a diff for OpenBSD which enforces a special mmap(2) option, MAP_STACK for the system stack and, if the check fails, just aborts the process.[1] (Please note that this differs from the meaning of MAP_STACK on some other operating systems) At first, everything looked fine, but later during the build, *sometimes* ghc (to be specific, inplace/lib/bin/ghc-stage2) got aborted after *many* succesfull runs of it (for example, while compiling the bundled haddock and after already a couple of haddock sources had been successfully compiled). So, if the stack pointer checking diff to OpenBSD is correct, and if I'm not running into a completely unrelated problem: does ghc and/or the runtime library sometimes move the system stack pointer to newly allocated/mapped memory? If so, where in the code? Please note: the check happens on traps and system calls, so the doesn't happen when the stack pointer is changed to newly allocated/mapped memory, but after the next trap or system call. Unfurtunately, I was stupid enough to drop my recent build logs and back traces, but they weren't very enlightening, anyway ;-) I may to get some more information tomorrow or on thursday. I'd appreciate any help on this. After all it's probably just a matter of changing one call to mmap(2), shielded by an #ifdef. Ciao and thanks in advance for any help, Kili [1]: https://marc.info/?l=openbsd-tech&m=151572838911297&w=2

2 3

FFI-free NaN checks? (isDoubleNan and friends)
by Mateusz Kowalczyk 06 Mar '18

06 Mar '18

Hi, Recently at a client I was profiling some code and isDoubleNaN lit up. We were checking a lot of doubles for NaN as that's what customer would send in. I went to investigate and I found that FFI is used to achieve this. I was always under the impression that FFI costs a little. I had at the time replaced the code with a hack with great results: ``` isNaN' :: Double -> Bool isNaN' d = d /= d ``` While this worked and provided good speedup in my case, this fails catastrophically if the program is compiled with -ffast-math. This is expected. I have since reverted it. Seeking an alternative solution I have thought about re-implementing the C code with a native Haskell version: after all it just checks a few bits. Apparently unsafeCoerce# and friends were a big no-no but I found https://phabricator.haskell.org/D3358 . I have implemented the code at the bottom of this post. Obviously it's missing endianness (compile-time switch). This seems to be faster for smaller `mkInput` list than Prelude.isNaN but slower slightly on the one below. The `/=` version is the fastest but very fragile. My question to you all is whether implementing a version of this function in Haskell makes sense and if not, why not? The stgDoubleToWord64 is implemented in CMM and I don't know anything about the costs of that. * Is there a cheaper alternative to FFI way? * If yes, does anyone know how to write it such that it compiles to same code but without the call overhead? I must have failed below as it's slower on some inputs. Basically if a faster way exists for isNaN, something I have to do a lot, I'd love to hear about it. I leave you with basic code I managed to come up with. 8.4.x only. ``` {-# LANGUAGE MagicHash #-} {-# OPTIONS_GHC -O2 -ddump-simpl -ddump-stg -ddump-to-file -ddump-asm #-} module Main (main) where import GHC.Float import GHC.Prim isNaN' :: Double -> Bool isNaN' d = d /= d isNaNBits :: Double -> Bool isNaNBits (D# d) = case (bits `and#` expMask) `eqWord#` expMask of 1# -> case bits `and#` mantissaMask of 0## -> False _ -> True _ -> False where bits :: Word# bits = stgDoubleToWord64 d expMask, mantissaMask :: Word# expMask = 0x7FF0000000000000## mantissaMask = 0x000FFFFFFFFFFFFF## main :: IO () main = sumFilter isNaN {-isNaN'-} {-isNaNBits-} (mkInput 100000000) `seq` pure () where nan :: Double nan = log (-1) mkInput :: Int -> [Double] mkInput n = take n $ cycle [1, nan] sumFilter :: (Double -> Bool) -> [Double] -> Double sumFilter p = Prelude.sum . Prelude.filter (not . p) ``` -- Mateusz K.

3 5

RE: Type checking expressions
by Simon Peyton Jones 05 Mar '18

05 Mar '18

Always cc ghc-devs! Bottle-necking on me may well yield a slow response! Or even Haskell-café. What is the type of (\x -> [x,y])? Where y is in scope with type y::a. Presumably something like a -> [a]? Or is it forall a. a -> [a]? And would your answer change if you had just (\x -> [x,x])? Generalisation is tricky, and for terms with non-closed types it is hard to know what you need in your use-case. A type like ‘a’ might be a very fine answer! A lot depends on precisely what you are trying to do. Simon From: Peter Podlovics [mailto:peter.d.podlovics@gmail.com] Sent: 05 March 2018 14:54 To: Simon Peyton Jones <simonpj(a)microsoft.com> Subject: Re: Type checking expressions My main concern with that approach is that it might not give the correct type. For example the hsPatType function only gives unconstrained types, so it is incorrect for any numeric literal, since it gives "a" instead of "Num a => a". So the question is whether it is possible to retrieve the context of the type variables as well. Also this problem may arise in the case of expressions as well, that is why I scrapped that approach and tried to type check the AST with the TcM monad directly, but without any success. Could you give me any leads on how to solve this problem? Thanks in advance, Peter On Mon, Mar 5, 2018 at 9:44 AM, Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: Peter My goal is to determine the type of every expression, pattern etc. in the syntax tree After type checking is complete, the syntax tree is liberally annotated with types. We do not yet have a function hsExprType :: HsExpr Id -> Type but we do have TcHsTyn.hsPatType :: Pat GhcTc -> Type and you or someone could readily make an equivalent for HsExpr. Most type errors are reported by adding an error constraint, but still returning an annotated tree. Some, I’m afraid, are still done in the old way, by throwing an exception – so you don’t get back an annotated tree in that case. But they are relatively rare. Others must have wanted something like this… Simon From: ghc-devs [mailto:ghc-devs-bounces@haskell.org<mailto:ghc-devs-bounces@haskell.org>] On Behalf Of Peter Podlovics Sent: 02 March 2018 12:05 To: ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> Subject: Fwd: Type checking expressions Hello everyone, I would like to ask for some advice regarding the type checker part of GHC. My goal is to determine the type of every expression, pattern etc. in the syntax tree. Currently the compiler doesn't store this information, so I have to type check manually. One important aspect is that the program may be ill-typed, but I still want to extract as much information as possible. I tried using local type checking functions (eg.: tcInferSigma), but whenever I used it on an expression that had some "out-of-scope" names in it, it failed. > f xs = length xs The reason was that xs was not in the local environment. My question is: how could I provide the necessary local environment for these type checking functions? Also in the general case, is it possible to somehow annotate each expression with its type during the type checking? The motivation for this is that I want to implement a tool that automatically corrects ill-typed programs based heuristics. For that I need to know the types of certain AST nodes. Peter Podlovics

3 2