- ghc-devs - Haskell.org

Viewing the types declared in GHC.Prim in local machine
by Abhiroop Sarkar 19 Mar '18

19 Mar '18

Is it possible to view the types generated in the GHC.Prim module on my local machine? The commentary[1] states that it is a virtual module and a source file including dummy declarations are available in this location: ` libraries/base/GHC/Prim.hs`, however, upon downloading and building the latest GHC codebase I could not find this dummy file on my machine. Do I have to modify my Makefile somehow to generate these dummy types? For building, I have followed the instructions mentioned here[2] and set `BuildFlavour = devel2`. Thanks, Abhiroop Sarkar [1]https://ghc.haskell.org/trac/ghc/wiki/Commentary/PrimOps [2]https://ghc.haskell.org/trac/ghc/wiki/Newcomers

3 2

Haskell Report 2010: pattern bindings
by Simon Peyton Jones 19 Mar '18

19 Mar '18

Thanks Jose. The other issue I have in mind is that of pattern bindings. Currently in the 2010 Haskell Report * The text on the monomorphism restriction<https://www.haskell.org/onlinereport/haskell2010/haskellch4.html#x10-880004…> (4.5.5) refers to “simple pattern bindings”. * It claims that a simple pattern binding “is a pattern binding in which the pattern consists of a single variable” * You’d expect “simple pattern binding” to be defined in 3.17.1 Patterns<https://www.haskell.org/onlinereport/haskell2010/haskellch3.html#x8-580003.…>. But it isn’t. * Instead, 4.4.3.2 Pattern bindings<https://www.haskell.org/onlinereport/haskell2010/haskellch4.html#x10-800004…> explicitly contradicts 4.5.5 by saying “a simple pattern binding has form p=e”. What a mess! The simplest way out is probably: * Define “simple pattern binding” to be of form x=e, in 3.17.1. * Fix the first para of 4.4.3.2. * Fix the cross-ref in 4.5.5 to refer to the definition of simple pattern. Sadly, 4.4.3.2 still is not very well defined. It’s supposed to say what pattern bindings mean, including top-level ones; but it does so by referring to 3.12 which does not handle top-level bindings. I’m not sure if this is worth fixing. Simon From: José Manuel Calderón Trilla <jmct(a)jmct.cc> Sent: 15 March 2018 23:17 To: Simon Peyton Jones <simonpj(a)microsoft.com>; haskell-prime(a)haskell.org; ghc-devs(a)haskell.org Subject: Re: [Haskell] The Haskell Report: who maintains it? All of us on the Haskell Language Committee have the ability to commit on that repo. I think typos are uncontroversial and I'll happily merge pull requests like that. I think the pull-request you point out suffered from the bystander effect, unfortunately. I'll review and merge it now. If you let me know the typo you'd like fixed I'll make sure that gets done as well. Cheers, José Manuel On Thu, Mar 15, 2018, at 6:52 PM, Simon Peyton Jones via Haskell wrote: 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. ________________________________ 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…>. _______________________________________________ Haskell mailing list Haskell(a)haskell.org<mailto:Haskell@haskell.org> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskel…>

1 0

Is "cml_cont" of CmmCall used in practice?
by Shao, Cheng 19 Mar '18

19 Mar '18

Hi all, Is the "cml_cont" field of the CmmCall variant is really used in practice? I traversed the output of raw Cmm produced by ghc compiling the whole base package, but the value of cml_cont is always Nothing. Regards, Shao Cheng

6 5

Re: [GHC] #13776: -ddump-splices produces unnecessarily qualified names for tuple and list types
by Soham Chowdhury 17 Mar '18

17 Mar '18

That sounds great! I never got around to working on this myself, feel free :) On Sun, Mar 18, 2018, 00:45 GHC <ghc-devs(a)haskell.org> wrote: > #13776: -ddump-splices produces unnecessarily qualified names for tuple > and list > types > -------------------------------------+------------------------------------- > Reporter: RyanGlScott | Owner: mrkgnao > Type: bug | Status: new > Priority: normal | Milestone: > Component: Template Haskell | Version: 8.0.1 > Resolution: | Keywords: newcomer > Operating System: Unknown/Multiple | Architecture: > | Unknown/Multiple > Type of failure: None/Unknown | Test Case: > Blocked By: | Blocking: > Related Tickets: | Differential Rev(s): > Wiki Page: | > -------------------------------------+------------------------------------- > > Comment (by ckoparkar): > > I'd like to work on this, if that's OK with @mrkgnao. > > I have a patch on my local machine > that does the right thing for the examples posted in the > description (and some tests: `th/T3319`, `th/T5700`, > `th/TH_foreignInterruptible`). > While I work on submitting that on Phabricator, I wanted to post a summary > here and get some early feedback. > > > (1) It seems that `showName` doesn't play a role in pretty-printing the > splices > with `-ddump-splices`. Instead, the `Outputable` instances in GHC do most > of the > work. Specifically, `Outputable RdrName` is responsible for printing out > the fully > qualified names in question. > > (2) When the Renamer typechecks & runs a splice (`RnSplice.runRnSplice`), > it > converts the splice to `HsSyn RdrName` (hence the `Outputable RdrName`). > `TcSplice.lookupThName` is involved in the process, which converts > a `TH.Name` to `Name` via `Convert.thRdrNameGuesses`. > > (3) For primitives like `[]`, `(:)` etc. `TH.dataToQa` generates a fully > qualified > global name, i.e `NameG NameSpace PkgName ModName`. > And the corresponding `RdrName` generated by `thRdrNameGuesses` is also > fully > qualified (`Orig Module OccName`). But this is not what we want for built- > in syntax. > > (4) So the "patch" is a simple change to modify this behavior. If > `thOrigRdrName` is > dealing with built-in syntax, it returns an `Exact Name` instead. > > {{{#!haskell > > thOrigRdrName :: String -> TH.NameSpace -> PkgName -> ModName -> RdrName > thOrigRdrName occ th_ns pkg mod = > let occ' = mk_occ (mk_ghc_ns th_ns) occ > in case isBuiltInOcc_maybe occ' of > Just name -> nameRdrName name > Nothing -> (mkOrig $! (mkModule (mk_pkg pkg) (mk_mod mod))) $! occ' > > }}} > > I ran the testsuite, and apart from some `perf` tests, almost everything > else worked. > > These tests fail: > > {{{ > ghci/linking/ghcilink003.run ghcilink003 [bad exit code] (normal) > > ghci/linking/ghcilink006.run ghcilink006 [bad exit code] (normal) > > th/T13366.run -- (gcc: error trying to exec 'cc1plus': > execvp: > -- No such file or directory) > }}} > > but there's a good chance that this is unrelated to the patch. > > > Does the overall approach seem reasonable ? I'll submit a patch soon. > > -- > Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13776#comment:5> > GHC <http://www.haskell.org/ghc/> > The Glasgow Haskell Compiler >

1 0

Custom ghcPrimIface for cross-compilation?
by Shao Cheng 16 Mar '18

16 Mar '18

Hi all, is it possible for a 64-bit ghc to emit 32-bit code, if I supply a custom ghcPrimIface via Hooks and also modify the platform flags in DynFlags? The module does not import Prelude and has no dependencies other than GHC.Prim.

3 2

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 10 Mar '18

10 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