From palotai.robin at gmail.com Tue Jul 4 05:44:41 2017 From: palotai.robin at gmail.com (Robin Palotai) Date: Tue, 4 Jul 2017 07:44:41 +0200 Subject: Crossreferenced GHC 8.0.2 In-Reply-To: References: Message-ID: FYI I added GHC 8.2.1-rc2 source to the index. Please tell if some source you would be interested in is obviously missing. Thanks! 2017-06-30 22:41 GMT+02:00 Robin Palotai : > Hello Matthew, > > Please see inline > > 2017-06-30 11:57 GMT+02:00 Matthew Pickering > : > >> Hi Robin, >> >> This looks really useful for developers. >> >> 1. Would it be possible to provide a script which allows developers to >> build this index for themselves easily? >> > > First, build and install the `ghc_kythe_wrapper` (instructions at > https://github.com/google/haskell-indexer). > > Then build GHC with `make`, and capture the build log. Here's the hacky > script I used: https://gist.github.com/robinp/ > 222cf3a39cc19178ec8691522056d7fe > > It filters the log and replaces GHC calls to call the wrapper, which emits > Kythe entries. > > Finally run `serve.sh` of the repo to postprocess and serve the entries > through HTTP. > > This is all pretty new, so feedback or questions welcome. If the method > distills, could try to write a more formal guide. > > >> 2. Is it possible to use this tool to detect dead code? Functions >> which are not used anywhere in the compiler. >> > > We'll get there eventually, but for now the emitted data is not > fine-grained enough. The main missing piece is recording what are exported > entities of a module (Kythe schema discussion in progress). Without this, > unused locals (which anyway surface with -Wall) would be presented and > noisy. > > Also, one would probably need to postprocess the data a bit for this, like > loading into a graph database or other ways. > > Did you see https://github.com/ndmitchell/weeder by the way? Might work. > > >> 3. How are you pretty printing the output whilst retaining the source >> formatting? I had a quick look at the source but I couldn't see where >> the output was being produced. >> >> > The haskell-indexer-frontend-kythe emits Kythe (http://kythe.io) schema > data. We just export the source offsets, and it's the Kythe postprocessing > / serving pipeline that does all the formatting. > > >> Cheers, >> >> Matt >> >> On Fri, Jun 30, 2017 at 8:55 AM, Robin Palotai >> wrote: >> > Hello GHC devs, >> > >> > I ran haskell-indexer [1] on the GHC 8.0.2 tarball, partly because I >> find >> > myself reading GHC source from time to time while working on the >> indexer, >> > and partly since it's fun. >> > >> > First, here you can click around [2] and find where beloved functions >> are >> > called from: >> > http://stuff.codereview.me/#ghc/compiler/hsSyn/HsBinds.hs?co >> rpus&signature >> > (scroll down a bit, imports are not linked yet). >> > >> > Second, the way I indexed was pretty simple. I took the output of >> `make`, >> > replaced the ghc used with the ghc_kythe_wrapper, and filtered the lines >> > which included '-c', since I noticed that those duplicate previous large >> > compile lines. This only indexes the stage1 compilation AFAIU. >> > >> > Feel free to suggest a better way to tap into the compilations to get >> > everything properly indexed (and possibly only once). >> > >> > Any comments welcome! >> > Robin >> > >> > [1]: https://github.com/google/haskell-indexer >> > >> > [2]: TLDR UI quirks: >> > - Click the :: in top-left to navigate file tree >> > - Ctrl-Click (on linux) to go directly to definition (otherwise click >> > stuff from bottom pane) >> > - Bottom pane often hides content, close it if stuck. >> > >> > _______________________________________________ >> > ghc-devs mailing list >> > ghc-devs at haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gael.deest at tweag.io Tue Jul 4 07:16:51 2017 From: gael.deest at tweag.io (=?UTF-8?B?RGVlc3QsIEdhw6ts?=) Date: Tue, 4 Jul 2017 09:16:51 +0200 Subject: Compilation time Message-ID: Hi all, As you are probably well aware, GHC performance has been a growing concern over the last few years. Many Haskell programmers complain that build time has significantly increased over the last few releases. However, to our knowledge, there isn't much data available to substantiate this claim and the severity of these problems is not well known. That's why we would like to bring some anecdotal evidence to your attention that seems to indicate really major performance regressions. We stumbled upon the CI of the data-reify package, which is built against all GHC releases since 2010 : https://travis-ci.org/ku-fpg/data-reify tl;dr: Build time has gone from 1 min 32s for GHC 7.0 to 4 min 35s for GHC 8.2. The 8.2 release alone seems to have increased compilation time by almost 2 minutes, with the current development branch bringing only minor performance improvements. Of course, this single data point is not sufficient to establish how severe and widespread these problems are. More data could probably be gathered from other packages. However, it certainly matches our (subjective) experience and we felt important to report it to you. Regards, -- Gaël Deest Tweag I/O -------------- next part -------------- An HTML attachment was scrubbed... URL: From palotai.robin at gmail.com Tue Jul 4 07:29:12 2017 From: palotai.robin at gmail.com (Robin Palotai) Date: Tue, 4 Jul 2017 09:29:12 +0200 Subject: Compilation time In-Reply-To: References: Message-ID: Note that Travis CI time is a sum of all operations, including fetching/saving caches etc. Opening the build log and looking for the compilation might be more revealing. For example, 7.10 seems ~10 seconds, 8.2.1 seems ~50 seconds. There are two issues I can see with this, that should be addressed by benchmarking: 1) The Travis CI build hosts might show varying performance across reruns due to shared machines. 2) Tuning the RTS params when invoking GHC as a compiler can yield significant benefits, at least on larger compilations (such as -A128m). It would probably be doable to fetch a set of packages from *ackage and build with various compilers under controlled circumstances? Robin 2017-07-04 9:16 GMT+02:00 Deest, Gaël : > Hi all, > > As you are probably well aware, GHC performance has been a growing concern > over the last few years. Many Haskell programmers complain that build time > has significantly increased over the last few releases. However, to our > knowledge, there isn't much data available to substantiate this claim and > the severity of these problems is not well known. > > That's why we would like to bring some anecdotal evidence to your > attention that seems to indicate really major performance regressions. We > stumbled upon the CI of the data-reify package, which is built against all > GHC releases since 2010 : > > https://travis-ci.org/ku-fpg/data-reify > > tl;dr: Build time has gone from 1 min 32s for GHC 7.0 to 4 min 35s for GHC > 8.2. The 8.2 release alone seems to have increased compilation time by > almost 2 minutes, with the current development branch bringing only minor > performance improvements. > > Of course, this single data point is not sufficient to establish how > severe and widespread these problems are. More data could probably be > gathered from other packages. However, it certainly matches our > (subjective) experience and we felt important to report it to you. > > Regards, > > -- > Gaël Deest > Tweag I/O > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewtpickering at gmail.com Tue Jul 4 07:31:27 2017 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Tue, 4 Jul 2017 08:31:27 +0100 Subject: Compilation time In-Reply-To: References: Message-ID: I tried the package with 8.2.1 and 8.0.2 and both build in less than 5 seconds with quite a large amount of variability. As Robin points out, there are varying factors which can account for longer build times on Travis. On Tue, Jul 4, 2017 at 8:16 AM, Deest, Gaël wrote: > Hi all, > > As you are probably well aware, GHC performance has been a growing concern > over the last few years. Many Haskell programmers complain that build time > has significantly increased over the last few releases. However, to our > knowledge, there isn't much data available to substantiate this claim and > the severity of these problems is not well known. > > That's why we would like to bring some anecdotal evidence to your attention > that seems to indicate really major performance regressions. We stumbled > upon the CI of the data-reify package, which is built against all GHC > releases since 2010 : > > https://travis-ci.org/ku-fpg/data-reify > > tl;dr: Build time has gone from 1 min 32s for GHC 7.0 to 4 min 35s for GHC > 8.2. The 8.2 release alone seems to have increased compilation time by > almost 2 minutes, with the current development branch bringing only minor > performance improvements. > > Of course, this single data point is not sufficient to establish how severe > and widespread these problems are. More data could probably be gathered from > other packages. However, it certainly matches our (subjective) experience > and we felt important to report it to you. > > Regards, > > -- > Gaël Deest > Tweag I/O > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From simonpj at microsoft.com Tue Jul 4 08:04:05 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 4 Jul 2017 08:04:05 +0000 Subject: Compilation time In-Reply-To: References: Message-ID: Thanks Gael. As you may know, we’ve focused a lot on compile time in the last year or so, and 8.4 is a lot faster. I think there are still plenty of bad cases, but things are better. Our compile-time perf page is here: https://ghc.haskell.org/trac/ghc/wiki/Performance/Compiler It links to a list of open perf tickets: https://ghc.haskell.org/trac/ghc/query?status=!closed&failure=Compile-time+performance+bug What helps above all are reproducible test cases. Package X compiles much more slowly with 8.2 than with 7.10, say. You did exactly that, thank you – can you open a ticket explaining exactly how to reproduce it, and what measurements you took. (Matthew’s numbers seemed two orders of magnitude different; I wonder why?) Another thing that is really helpful is people who characterise what the problem is: * Is GHC generating a lot more code? -dshow-passes can reveal this. * Is it GHC at all, or is it link-times, or some other part of the tool chain? * If it is GHC, and the output of compilation is no bigger than before, where is the time going? -dshow-passes gives a rough idea of that too. * Is there a particular characteristic of the program that seems to trigger the poor behaviour? Can you accentuate that characteristic to make it behave wildly badly? Everyone: GHC is your compiler! We need your help. Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Deest, Gaël Sent: 04 July 2017 08:17 To: ghc-devs at haskell.org Cc: Manuel Chakravarty Subject: Compilation time Hi all, As you are probably well aware, GHC performance has been a growing concern over the last few years. Many Haskell programmers complain that build time has significantly increased over the last few releases. However, to our knowledge, there isn't much data available to substantiate this claim and the severity of these problems is not well known. That's why we would like to bring some anecdotal evidence to your attention that seems to indicate really major performance regressions. We stumbled upon the CI of the data-reify package, which is built against all GHC releases since 2010 : https://travis-ci.org/ku-fpg/data-reify tl;dr: Build time has gone from 1 min 32s for GHC 7.0 to 4 min 35s for GHC 8.2. The 8.2 release alone seems to have increased compilation time by almost 2 minutes, with the current development branch bringing only minor performance improvements. Of course, this single data point is not sufficient to establish how severe and widespread these problems are. More data could probably be gathered from other packages. However, it certainly matches our (subjective) experience and we felt important to report it to you. Regards, -- Gaël Deest Tweag I/O -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at cs.brynmawr.edu Tue Jul 4 13:57:27 2017 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Tue, 4 Jul 2017 09:57:27 -0400 Subject: Deadline in 2 days: Haskell Implementors' Workshop Call for Talks In-Reply-To: <89244F5C-058B-426D-84A4-4A4D62C2E880@cs.brynmawr.edu> References: <89244F5C-058B-426D-84A4-4A4D62C2E880@cs.brynmawr.edu> Message-ID: <306EAE31-D51E-465A-A521-69946C7639CE@cs.brynmawr.edu> Call for Contributions ACM SIGPLAN Haskell Implementors' Workshop http://icfp17.sigplan.org/track/hiw-2017 Oxford, UK, 9 September, 2017 Co-located with ICFP 2017 http://www.icfpconference.org/icfp2017/ Important dates --------------- Proposal Deadline: Thursday, 6 July, 2017 Notification: Thursday, 20 July, 2017 Workshop: Saturday, 9 September, 2017 The 9th Haskell Implementors' Workshop is to be held alongside ICFP 2017 this year in Oxford. It is a forum for people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure, to share their work and discuss future directions and collaborations with others. Talks and/or demos are proposed by submitting an abstract, and selected by a small program committee. There will be no published proceedings. The workshop will be informal and interactive, with open spaces in the timetable and room for ad-hoc discussion, demos, and impromptu short talks. Scope and target audience ------------------------- It is important to distinguish the Haskell Implementors' Workshop from the Haskell Symposium which is also co-located with ICFP 2017. The Haskell Symposium is for the publication of Haskell-related research. In contrast, the Haskell Implementors' Workshop will have no proceedings -- although we will aim to make talk videos, slides and presented data available with the consent of the speakers. The Implementors' Workshop is an ideal place to describe a Haskell extension, describe works-in-progress, demo a new Haskell-related tool, or even propose future lines of Haskell development. Members of the wider Haskell community encouraged to attend the workshop -- we need your feedback to keep the Haskell ecosystem thriving. Students working with Haskell are specially encouraged to share their work. The scope covers any of the following topics. There may be some topics that people feel we've missed, so by all means submit a proposal even if it doesn't fit exactly into one of these buckets: * Compilation techniques * Language features and extensions * Type system implementation * Concurrency and parallelism: language design and implementation * Performance, optimisation and benchmarking * Virtual machines and run-time systems * Libraries and tools for development or deployment Talks ----- We invite proposals from potential speakers for talks and demonstrations. We are aiming for 20-minute talks with 5 minutes for questions and changeovers. We want to hear from people writing compilers, tools, or libraries, people with cool ideas for directions in which we should take the platform, proposals for new features to be implemented, and half-baked crazy ideas. Please submit a talk title and abstract of no more than 300 words. Submissions should be made via HotCRP. The website is: https://icfp-hiw17.hotcrp.com/ We will also have a lightning talks session which will be organised on the day. These talks will be 5-10 minutes, depending on available time. Suggested topics for lightning talks are to present a single idea, a work-in-progress project, a problem to intrigue and perplex Haskell implementors, or simply to ask for feedback and collaborators. Program Committee ----------------- * Richard A. Eisenberg -- chair (Bryn Mawr College) * Adam Gundry (Well-Typed) * Bartosz Nitka (Facebook) * Wren Romano (X, formerly Google[x]) * Alejandro Serrano Mena (Utrecht University) * Jan Stolarek (University of Edinburgh) Contact ------- * Richard A. Eisenberg _______________________________________________ Haskell mailing list Haskell at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell From edvard at hubinette.me Wed Jul 5 16:20:22 2017 From: edvard at hubinette.me (=?UTF-8?Q?Edvard_H=C3=BCbinette?=) Date: Wed, 05 Jul 2017 16:20:22 +0000 Subject: Which stable GHC release is expected to have support for linear types? Message-ID: Hi Wolfgang, I've put together a small README for getting this up and running (both for using stack with pre-built Docker images, and from source). It can be found in the repository here: https://github.com/tweag/ghc/tree/linear-types. Hope this will help! Cheers, Edvard Hübinette -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Thu Jul 6 01:10:39 2017 From: ben at smart-cactus.org (Ben Gamari) Date: Wed, 05 Jul 2017 21:10:39 -0400 Subject: Updating Phabricator Message-ID: <87r2xu8j5c.fsf@ben-laptop.smart-cactus.org> I'll be upgrading Phabricator in a few minutes. I expect this will only take 30 minutes or so and will let you know when it's done. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at smart-cactus.org Thu Jul 6 01:30:13 2017 From: ben at smart-cactus.org (Ben Gamari) Date: Wed, 05 Jul 2017 21:30:13 -0400 Subject: Updating Phabricator In-Reply-To: <87r2xu8j5c.fsf@ben-laptop.smart-cactus.org> References: <87r2xu8j5c.fsf@ben-laptop.smart-cactus.org> Message-ID: <87lgo28i8q.fsf@ben-laptop.smart-cactus.org> Ben Gamari writes: > I'll be upgrading Phabricator in a few minutes. I expect this will only take > 30 minutes or so and will let you know when it's done. > The upgrade is complete. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at smart-cactus.org Thu Jul 6 18:55:00 2017 From: ben at smart-cactus.org (Ben Gamari) Date: Thu, 06 Jul 2017 14:55:00 -0400 Subject: Listing Trac keywords Message-ID: <871spt8kfv.fsf@ben-laptop.smart-cactus.org> Hello everyone, Today I took a few minutes to write some SQL to generate a list of all of the keywords in Trac tickets. There are still a few quirks (e.g. no hyperlinking of ticket numbers, some mysterious duplicate ticket numbers). Nevertheless, it's better than nothing. The result can be found here [1]. Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/report/25?sort=n_tickets&asc=0&page=1 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From wolfgang-it at jeltsch.info Fri Jul 7 13:16:20 2017 From: wolfgang-it at jeltsch.info (Wolfgang Jeltsch) Date: Fri, 07 Jul 2017 16:16:20 +0300 Subject: Which stable GHC release is expected to have support for linear types? In-Reply-To: References: Message-ID: <1499433380.2497.187.camel@jeltsch.info> Hi, Edvard! Thanks a lot for putting this together. This is very helpful indeed. All the best, Wolfgang Am Mittwoch, den 05.07.2017, 16:20 +0000 schrieb Edvard Hübinette: > Hi Wolfgang,  > > I've put together a small README for getting this up and running (both > for using stack with pre-built Docker images, and from source). It can > be found in the repository here: https://github.com/tweag/ghc/tree/lin > ear-types. > > Hope this will help! > > Cheers, > Edvard Hübinette From ryan.gl.scott at gmail.com Fri Jul 7 15:26:09 2017 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Fri, 7 Jul 2017 08:26:09 -0700 Subject: Compilation time Message-ID: Another things to note about 8.2 build times is that a bulk of the time is probably being spent during the linking phase. This is because GHC 8.2 has switched over to split-sections by default, but unfortunately, old versions of the BFD linker take a long time to link code that uses split-sections (see the discussion at [1]). There is ongoing work (which should hopefully land before the final 8.2 release) to use gold instead of BFD as the default linker when available, which will reduce linking times dramatically. Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/ticket/13739 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Fri Jul 7 16:28:13 2017 From: ben at smart-cactus.org (Ben Gamari) Date: Fri, 07 Jul 2017 12:28:13 -0400 Subject: Compilation time In-Reply-To: References: Message-ID: <87mv8g6wki.fsf@ben-laptop.smart-cactus.org> Ryan Scott writes: > Another things to note about 8.2 build times is that a bulk of the time is > probably being spent during the linking phase. This is because GHC 8.2 has > switched over to split-sections by default, but unfortunately, old versions > of the BFD linker take a long time to link code that uses split-sections > (see the discussion at [1]). There is ongoing work (which should hopefully > land before the final 8.2 release) to use gold instead of BFD as the > default linker when available, which will reduce linking times dramatically. > Indeed it has already landed. See #13541. In short, ./configure will now choose to use ld.gold or ld.lld if available (although this can be disabled using the --disable-ld-override configure flag). Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at well-typed.com Fri Jul 7 18:22:42 2017 From: ben at well-typed.com (Ben Gamari) Date: Fri, 07 Jul 2017 14:22:42 -0400 Subject: [ANNOUNCE] GHC 8.2.1 release candidate 3 available Message-ID: <87h8yo6r9p.fsf@ben-laptop.smart-cactus.org> Hello everyone, I am pleased to at long last announce the third (and almost certainly last) release candidate of GHC 8.2.1. Binary and source distributions can be found at, https://downloads.haskell.org/~ghc/8.2.1-rc3/ This release candidate fixes a number of regressions from 8.0.2 found in -rc2, as well as a major correctness bug (#13615) present in several previous GHC major releases. Users taking advantage of parallelism in their programs will be strongly encouraged to upgrade to 8.2.1 once it is released. Among the other issues resolved in this candidate are, * Functionality allowing GHC to automatically use the ld.gold linker when available (see #13541). Not only has there recently been significant user demand for this feature, but this also serves to work around a performance bug in BFD ld affecting GHC 8.2 (#13739) * A regression resulting in the package cache file to be out-of-date after binary distribution installation (#13375) * Numerous type-checker bugs (#13625, #1370, #13782, #13871, #13594, #13879, #13881, #13875) * A bug wherein a thread blocked on a BLACKHOLE may not be woken up (#13751) * and many more... There are a few changes in release-engineering matters that should be mentioned, * Binary distributions for CentOS 6.7 have been dropped due to the release of CentOS 7.0 which can use Debian 8 binaries. If you would like us to continue to produce CentOS 6.7 bindists please let me know. * GHC HQ now also provides FreeBSD and OpenBSD distributions for amd64; this will allow us to more quickly ship distributions to users by eliminating the need for a long lag time between source release availability and having all binary distributions available. * There is a technology-preview of an AArch64 Linux binary distribution, as well as an ARM Linux build (although the latter won't be uploaded until a few hours from now). AArch64 support is quite preliminary but should be stable in 8.4 thanks to further linker fixes by Moritz Angerman. ARM should be stable. As always, let us know if you encounter problems. If all goes well we will hopefully have a final 8.2.1 release in the next two weeks. Finally, thanks for your patience during this admittedly quite drawn out release cycle. While it has been long, we are confident that the result will be worth the wait. Moreover, we have been steadily working on infrastructure which should shrink future release cycles and give us better testing between releases. More details on this coming soon. Happy testing, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From qdunkan at gmail.com Fri Jul 7 22:21:42 2017 From: qdunkan at gmail.com (Evan Laforge) Date: Fri, 7 Jul 2017 15:21:42 -0700 Subject: Compilation time In-Reply-To: <87mv8g6wki.fsf@ben-laptop.smart-cactus.org> References: <87mv8g6wki.fsf@ben-laptop.smart-cactus.org> Message-ID: On Fri, Jul 7, 2017 at 9:28 AM, Ben Gamari wrote: > Ryan Scott writes: > >> Another things to note about 8.2 build times is that a bulk of the time is >> probably being spent during the linking phase. This is because GHC 8.2 has >> switched over to split-sections by default, but unfortunately, old versions >> of the BFD linker take a long time to link code that uses split-sections >> (see the discussion at [1]). There is ongoing work (which should hopefully >> land before the final 8.2 release) to use gold instead of BFD as the >> default linker when available, which will reduce linking times dramatically. >> > Indeed it has already landed. See #13541. > > In short, ./configure will now choose to use ld.gold or ld.lld if > available (although this can be disabled using the --disable-ld-override > configure flag). Just from curiosity, does this apply to OS X? Of course, gold is ELF-only, so it surely doesn't apply, but there's still lld. OS X uses clang to compile so I thought it might already use lld, but the 'ld -v' output looks different, and lld.llvm.org implies it's a replacement for OS X ld, so maybe not. But it doesn't look like GNU ld either, so maybe it's not affected by the BFD bug? I'll try 8.2 on OS X and see if the link time changes. From ben at smart-cactus.org Fri Jul 7 23:33:58 2017 From: ben at smart-cactus.org (Ben Gamari) Date: Fri, 07 Jul 2017 19:33:58 -0400 Subject: Compilation time In-Reply-To: References: <87mv8g6wki.fsf@ben-laptop.smart-cactus.org> Message-ID: <878tjz7rfd.fsf@ben-laptop.smart-cactus.org> Evan Laforge writes: > On Fri, Jul 7, 2017 at 9:28 AM, Ben Gamari wrote: >> >> In short, ./configure will now choose to use ld.gold or ld.lld if >> available (although this can be disabled using the --disable-ld-override >> configure flag). > > Just from curiosity, does this apply to OS X? Of course, gold is > ELF-only, so it surely doesn't apply, but there's still lld. OS X > uses clang to compile so I thought it might already use lld, but the > 'ld -v' output looks different, and lld.llvm.org implies it's a > replacement for OS X ld, so maybe not. But it doesn't look like GNU > ld either, so maybe it's not affected by the BFD bug? > > I'll try 8.2 on OS X and see if the link time changes. 8.2 will prefer both gold and lld over bfd ld. However two conditions must hold for these to be used, * The ld.lld/ld.gold executable must be in $PATH (or explicitly named by passing the LD variable to configure) * $CC must understand the `-fuse-ld={gold,lld}` option. For (IMHO quite silly) political reasons, gcc doesn't support `-fuse-ld=lld`. Debian happens to patch gcc to add support but I don't know how common this is in other distributions. Unfortunately, some earlier `gcc` versions didn't fail if given a `-fuse-ld` option that they didn't understand. Sadly we have no reliable way to detect this, so in this case we may end up passing a `-fuse-ld` option that gcc simply ignores. In the case of OS X we use Apple's own home-grown linker. I'm not sure whether/how OS X's gcc wrapper treats `-fuse-ld` (beyond that it doesn't error if the flag is given). I also don't know whether lld is currently a capable replacement for OS X ld. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From moritz.angermann at gmail.com Sat Jul 8 01:45:49 2017 From: moritz.angermann at gmail.com (Moritz Angermann) Date: Sat, 8 Jul 2017 09:45:49 +0800 Subject: Compilation time In-Reply-To: <878tjz7rfd.fsf@ben-laptop.smart-cactus.org> References: <87mv8g6wki.fsf@ben-laptop.smart-cactus.org> <878tjz7rfd.fsf@ben-laptop.smart-cactus.org> Message-ID: For those of us who are on macOS, you usually do not have any gcc, it’s all clang behind the curtains. E.g. see $ /usr/bin/gcc --version Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 8.1.0 (clang-802.0.42) Target: x86_64-apple-darwin16.6.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin ld, is apples ld64 (see https://opensource.apple.com/source/ld64/) $ /usr/bin/ld -v @(#)PROGRAM:ld PROJECT:ld64-278.4 configured to support archs: armv6 armv7 armv7s arm64 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em (tvOS) LTO support using: LLVM version 8.1.0, (clang-802.0.42) TAPI support using: Apple TAPI version 1.33.11 if you end up having clang+llvm-4.0.0-x86_64-apple-darwin/bin or similar in your path, you WILL have `ld.lld`, but that one is an ELF linker, which on a MachO platform won’t be very useful (and will therefore fail to link MachO objects). Llvm’s `lld` will provide you with the following semi helpful note: $ lld lld is a generic driver. Invoke ld.lld (Unix), ld (Mac) or lld-link (Windows) instead. however, my copy of clang+llvm, does only ship ld.lld, and lld-link, but not `ld`. Thus, if you end up having the llvm tools (and ld.lld) in your PATH, you will need to set `--disable-ld-override` during configure on macOS, or your ghc build will fail, because you end up trying to link MachO object files with an ELF only linker. Cheers, Moritz > On Jul 8, 2017, at 7:33 AM, Ben Gamari wrote: > > Evan Laforge writes: > >> On Fri, Jul 7, 2017 at 9:28 AM, Ben Gamari wrote: >>> >>> In short, ./configure will now choose to use ld.gold or ld.lld if >>> available (although this can be disabled using the --disable-ld-override >>> configure flag). >> >> Just from curiosity, does this apply to OS X? Of course, gold is >> ELF-only, so it surely doesn't apply, but there's still lld. OS X >> uses clang to compile so I thought it might already use lld, but the >> 'ld -v' output looks different, and lld.llvm.org implies it's a >> replacement for OS X ld, so maybe not. But it doesn't look like GNU >> ld either, so maybe it's not affected by the BFD bug? >> >> I'll try 8.2 on OS X and see if the link time changes. > > 8.2 will prefer both gold and lld over bfd ld. However two conditions > must hold for these to be used, > > * The ld.lld/ld.gold executable must be in $PATH (or explicitly named > by passing the LD variable to configure) > > * $CC must understand the `-fuse-ld={gold,lld}` option. For (IMHO quite > silly) political reasons, gcc doesn't support `-fuse-ld=lld`. Debian > happens to patch gcc to add support but I don't know how common this > is in other distributions. > > Unfortunately, some earlier `gcc` versions didn't fail if given a > `-fuse-ld` option that they didn't understand. Sadly we have no reliable > way to detect this, so in this case we may end up passing a `-fuse-ld` > option that gcc simply ignores. > > In the case of OS X we use Apple's own home-grown linker. I'm not sure > whether/how OS X's gcc wrapper treats `-fuse-ld` (beyond that it doesn't > error if the flag is given). I also don't know whether lld is currently a > capable replacement for OS X ld. > > Cheers, > > - Ben > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From ben at smart-cactus.org Sat Jul 8 02:37:54 2017 From: ben at smart-cactus.org (Ben Gamari) Date: Fri, 07 Jul 2017 22:37:54 -0400 Subject: Compilation time In-Reply-To: References: <87mv8g6wki.fsf@ben-laptop.smart-cactus.org> <878tjz7rfd.fsf@ben-laptop.smart-cactus.org> Message-ID: <8760f37iwt.fsf@ben-laptop.smart-cactus.org> Moritz Angermann writes: > For those of us who are on macOS, ... > Thus, if you end up having the llvm tools (and ld.lld) in your PATH, you > will need to set `--disable-ld-override` during configure on macOS, or your > ghc build will fail, because you end up trying to link MachO object files > with an ELF only linker. > Yikes, this is quite bad. We'll need to teach autoconf to recognize this before the release. Thanks for bringing this up! Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From karel.gardas at centrum.cz Sat Jul 8 06:47:35 2017 From: karel.gardas at centrum.cz (Karel Gardas) Date: Sat, 08 Jul 2017 08:47:35 +0200 Subject: Compilation time In-Reply-To: <878tjz7rfd.fsf@ben-laptop.smart-cactus.org> References: <87mv8g6wki.fsf@ben-laptop.smart-cactus.org> <878tjz7rfd.fsf@ben-laptop.smart-cactus.org> Message-ID: <59608007.5060007@centrum.cz> On 07/ 8/17 01:33 AM, Ben Gamari wrote: > 8.2 will prefer both gold and lld over bfd ld. However two conditions > must hold for these to be used, > > * The ld.lld/ld.gold executable must be in $PATH (or explicitly named > by passing the LD variable to configure) > > * $CC must understand the `-fuse-ld={gold,lld}` option. For (IMHO quite > silly) political reasons, gcc doesn't support `-fuse-ld=lld`. Debian > happens to patch gcc to add support but I don't know how common this > is in other distributions. > > Unfortunately, some earlier `gcc` versions didn't fail if given a > `-fuse-ld` option that they didn't understand. Sadly we have no reliable > way to detect this, so in this case we may end up passing a `-fuse-ld` > option that gcc simply ignores. I've run into this issue too, but it looks like the issue is not in gcc, but in ghc's aclocal.m4 (one '$' missing). Attached patch solves this on OpenBSD 6.1-current where HEAD fails building on linker error. It passes build-id option to the gcc's linker (bfd ld) which does not support it as configure detects lld is presented on this system too. Sorry for not being able to push that through usual arc. Thanks, Karel -------------- next part -------------- diff --git a/aclocal.m4 b/aclocal.m4 index 677c0e77bc..921f137b95 100644 --- a/aclocal.m4 +++ b/aclocal.m4 @@ -2278,6 +2278,7 @@ AC_DEFUN([FIND_LD],[ [enable_ld_override=yes]) if test "x$enable_ld_override" = "xyes"; then + BACKUP_LD="$LD" AC_CHECK_TARGET_TOOLS([LD], [ld.gold ld.lld ld]) UseLd='' @@ -2288,8 +2289,13 @@ AC_DEFUN([FIND_LD],[ "LLD"*) FP_CC_LINKER_FLAG_TRY(lld, $2) ;; *) AC_MSG_NOTICE([unknown linker version $out]) ;; esac - if test "z$2" = "z"; then + if test "z$$2" = "z"; then AC_MSG_NOTICE([unable to convince '$CC' to use linker '$LD']) + # disable ld override and recheck with just ld + enable_ld_override=no + LD="$BACKUP_LD" + unset ac_cv_prog_ac_ct_LD + AC_CHECK_TARGET_TOOL([LD], [ld]) fi else AC_CHECK_TARGET_TOOL([LD], [ld]) From matthewtpickering at gmail.com Sat Jul 8 22:20:39 2017 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Sat, 8 Jul 2017 23:20:39 +0100 Subject: can't validate on Linux In-Reply-To: <7093FA1B-E20D-44E3-AA6E-CC307BA55924@cs.brynmawr.edu> References: <3491BAC5-ECB8-4C67-B35F-8EE8F8805F5A@cs.brynmawr.edu> <87r320lu06.fsf@ben-laptop.smart-cactus.org> <7093FA1B-E20D-44E3-AA6E-CC307BA55924@cs.brynmawr.edu> Message-ID: Hi Richard, I seem to be running into a similar error message when using "make install", did you ever find a solution to the problem? Matt On Mon, Mar 13, 2017 at 10:17 PM, Richard Eisenberg wrote: > >> On Mar 13, 2017, at 5:57 PM, Ben Gamari wrote: >> >> Richard, this is on Linux, yes? > > Yes, it is. But I have now noticed other aspects of some very strange behavior regarding the filesystem on my Linux server, so the problem may be unrelated to GHC. (Example of other problem: running the testsuite, with `make`, reveals tons of stderr mismatches. Some digging reveals that the .run.stderr files are sometimes truncated.) > > So, thanks for the offers for help, but I’ve passed this problem up to my sysadmin. > > Thanks, > Richard > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From asr at eafit.edu.co Sun Jul 9 06:05:44 2017 From: asr at eafit.edu.co (=?UTF-8?B?QW5kcsOpcyBTaWNhcmQtUmFtw61yZXo=?=) Date: Sun, 9 Jul 2017 01:05:44 -0500 Subject: [ANNOUNCE] GHC 8.2.1 release candidate 3 available In-Reply-To: <87h8yo6r9p.fsf@ben-laptop.smart-cactus.org> References: <87h8yo6r9p.fsf@ben-laptop.smart-cactus.org> Message-ID: Hi Ben, On 7 July 2017 at 13:22, Ben Gamari wrote: > > I am pleased to at long last announce the third (and almost certainly > last) release candidate of GHC 8.2.1. Binary and source distributions > can be found at, > > https://downloads.haskell.org/~ghc/8.2.1-rc3/ Thanks for releasing GHC 8.2.1 RC 3. While testing this RC candidate on Agda we found a compilation error. The error was caused by an *unused* module which *is* compiled by this RC but it *is not* compiled by previous versions of GHC including 8.2.1 RC 2. This module was listed in the `other-modules` field of the `test-suite` section in the .cabal file. After removing the offending module, we didn't find more problems. While I think GHC is doing the right thing here, it is not an obvious error on medium size projects like Agda. This is the reason for sharing this information. Best, -- Andrés La información contenida en este correo electrónico está dirigida únicamente a su destinatario y puede contener información confidencial, material privilegiado o información protegida por derecho de autor. Está prohibida cualquier copia, utilización, indebida retención, modificación, difusión, distribución o reproducción total o parcial. Si usted recibe este mensaje por error, por favor contacte al remitente y elimínelo. La información aquí contenida es responsabilidad exclusiva de su remitente por lo tanto la Universidad EAFIT no se hace responsable de lo que el mensaje contenga. The information contained in this email is addressed to its recipient only and may contain confidential information, privileged material or information protected by copyright. Its prohibited any copy, use, improper retention, modification, dissemination, distribution or total or partial reproduction. If you receive this message by error, please contact the sender and delete it. The information contained herein is the sole responsibility of the sender therefore Universidad EAFIT is not responsible for what the message contains. From david at well-typed.com Sun Jul 9 16:50:27 2017 From: david at well-typed.com (David Feuer) Date: Sun, 09 Jul 2017 12:50:27 -0400 Subject: [ANNOUNCE] GHC 8.2.1 release candidate 3 available In-Reply-To: References: <87h8yo6r9p.fsf@ben-laptop.smart-cactus.org> Message-ID: <6956827.s7k5c3tXxK@squirrel> On Sunday, July 9, 2017 1:05:44 AM EDT Andrés Sicard-Ramírez wrote: > While testing this RC candidate on Agda we found a compilation error. > > The error was caused by an *unused* module which *is* compiled by this > RC but it *is not* compiled by previous versions of GHC including > 8.2.1 RC 2. This module was listed in the `other-modules` field of the > `test-suite` section in the .cabal file. After removing the offending > module, we didn't find more problems. > > While I think GHC is doing the right thing here, it is not an obvious > error on medium size projects like Agda. This is the reason for > sharing this information. Are you saying that Cabal is now compiling an unused module with legitimate errors that GHC detects? If so, that sounds like a Cabal issue rather than a GHC one. As you haven't offered example code, it's a bit hard to see just what you mean. From matthewtpickering at gmail.com Sun Jul 9 20:15:01 2017 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Sun, 9 Jul 2017 21:15:01 +0100 Subject: can't validate on Linux In-Reply-To: References: <3491BAC5-ECB8-4C67-B35F-8EE8F8805F5A@cs.brynmawr.edu> <87r320lu06.fsf@ben-laptop.smart-cactus.org> <7093FA1B-E20D-44E3-AA6E-CC307BA55924@cs.brynmawr.edu> Message-ID: geekosaur suggests on IRC that this might be related to a SELinux security policy. "what might be possible is that hLock uses fcntl locking, ghc-pkg opens a database r/o if it can't open it r/w, and it tried to acquire a write lock (which will fail with EBADF if the file descriptor is only open for read). and there is an SElinux context prohibiting your process opening the db for write" On Sat, Jul 8, 2017 at 11:20 PM, Matthew Pickering wrote: > Hi Richard, > > I seem to be running into a similar error message when using "make > install", did you ever find a solution to the problem? > > Matt > > On Mon, Mar 13, 2017 at 10:17 PM, Richard Eisenberg wrote: >> >>> On Mar 13, 2017, at 5:57 PM, Ben Gamari wrote: >>> >>> Richard, this is on Linux, yes? >> >> Yes, it is. But I have now noticed other aspects of some very strange behavior regarding the filesystem on my Linux server, so the problem may be unrelated to GHC. (Example of other problem: running the testsuite, with `make`, reveals tons of stderr mismatches. Some digging reveals that the .run.stderr files are sometimes truncated.) >> >> So, thanks for the offers for help, but I’ve passed this problem up to my sysadmin. >> >> Thanks, >> Richard >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From wolfgang-it at jeltsch.info Sun Jul 9 20:35:46 2017 From: wolfgang-it at jeltsch.info (Wolfgang Jeltsch) Date: Sun, 09 Jul 2017 23:35:46 +0300 Subject: Which stable GHC release is expected to have support for linear types? In-Reply-To: References: Message-ID: <1499632546.2497.258.camel@jeltsch.info> Hi, Edvard! I generally followed the instructions on     https://github.com/tweag/ghc/tree/linear-types#building-from-source  , but when running     git checkout tweag/linear-types  , I got the following error message: > fatal: Not a git repository: ${BASEDIR}/ghc/.git/modules/.arc-linters/arcanist-external-json-linter I guess this is because my local directory is not named “ghc”, but “ghc- linear”. In my opinion, the repository should not assume that a local copy of it resides in a directory of a certain name. Is this a GHC issue or an issue with your linear-types branch? All the best, Wolfgang Am Mittwoch, den 05.07.2017, 16:20 +0000 schrieb Edvard Hübinette: > Hi Wolfgang,  > > I've put together a small README for getting this up and running (both > for using stack with pre-built Docker images, and from source). It can > be found in the repository here: https://github.com/tweag/ghc/tree/lin > ear-types. > > Hope this will help! > > Cheers, > Edvard Hübinette From allbery.b at gmail.com Sun Jul 9 21:13:22 2017 From: allbery.b at gmail.com (Brandon Allbery) Date: Sun, 9 Jul 2017 17:13:22 -0400 Subject: Which stable GHC release is expected to have support for linear types? In-Reply-To: <1499632546.2497.258.camel@jeltsch.info> References: <1499632546.2497.258.camel@jeltsch.info> Message-ID: On Sun, Jul 9, 2017 at 4:35 PM, Wolfgang Jeltsch wrote: > I got the following error message: > > > fatal: Not a git repository: ${BASEDIR}/ghc/.git/modules/. > arc-linters/arcanist-external-json-linter > > I guess this is because my local directory is not named “ghc”, but “ghc- > linear”. In my opinion, the repository should not assume that a local > copy of it resides in a directory of a certain name. Is this a GHC issue > or an issue with your linear-types branch? > Sounds like they forgot to undo some Phabricator-specific setup from the master ghc repo. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From asr at eafit.edu.co Mon Jul 10 00:38:38 2017 From: asr at eafit.edu.co (=?UTF-8?B?QW5kcsOpcyBTaWNhcmQtUmFtw61yZXo=?=) Date: Sun, 9 Jul 2017 19:38:38 -0500 Subject: [ANNOUNCE] GHC 8.2.1 release candidate 3 available In-Reply-To: <6956827.s7k5c3tXxK@squirrel> References: <87h8yo6r9p.fsf@ben-laptop.smart-cactus.org> <6956827.s7k5c3tXxK@squirrel> Message-ID: On 9 July 2017 at 11:50, David Feuer wrote: > On Sunday, July 9, 2017 1:05:44 AM EDT Andrés Sicard-Ramírez wrote: >> While testing this RC candidate on Agda we found a compilation error. >> >> The error was caused by an *unused* module which *is* compiled by this >> RC but it *is not* compiled by previous versions of GHC including >> 8.2.1 RC 2. This module was listed in the `other-modules` field of the >> `test-suite` section in the .cabal file. After removing the offending >> module, we didn't find more problems. >> >> While I think GHC is doing the right thing here, it is not an obvious >> error on medium size projects like Agda. This is the reason for >> sharing this information. > > Are you saying that Cabal is now compiling an unused module with legitimate > errors that GHC detects? No. >From a personal message by Herbert: On 9 July 2017 at 03:53, Herbert Valerio Riedel wrote: > - Prior to Cabal 2.0, the modules listed in `other-modules` were only > passed to GHC for library stanzas, but not to > executables/benchmarks/test stanzas. > Example: Let's suppose we have the following information in the .cabal file: test-suite foo-test other-modules: M1 , M2 , M3 , Bad where `Bad.hs` a) is not used by `foo-test` and b) generates a compilation error. Due to the above new feature mentioned by Herbert, GHC 8.2.1 RC3/Cabal 2.0 *correctly* report an error in `Bad.hs` but previous versions of GHC/Cabal don't. Best, -- Andrés La información contenida en este correo electrónico está dirigida únicamente a su destinatario y puede contener información confidencial, material privilegiado o información protegida por derecho de autor. Está prohibida cualquier copia, utilización, indebida retención, modificación, difusión, distribución o reproducción total o parcial. Si usted recibe este mensaje por error, por favor contacte al remitente y elimínelo. La información aquí contenida es responsabilidad exclusiva de su remitente por lo tanto la Universidad EAFIT no se hace responsable de lo que el mensaje contenga. The information contained in this email is addressed to its recipient only and may contain confidential information, privileged material or information protected by copyright. Its prohibited any copy, use, improper retention, modification, dissemination, distribution or total or partial reproduction. If you receive this message by error, please contact the sender and delete it. The information contained herein is the sole responsibility of the sender therefore Universidad EAFIT is not responsible for what the message contains. From edvard at hubinette.me Mon Jul 10 09:22:35 2017 From: edvard at hubinette.me (=?UTF-8?Q?Edvard_H=C3=BCbinette?=) Date: Mon, 10 Jul 2017 11:22:35 +0200 Subject: Which stable GHC release is expected to have support for linear types? In-Reply-To: <1499632546.2497.258.camel@jeltsch.info> References: <1499632546.2497.258.camel@jeltsch.info> Message-ID: Hi Wolfgang, the directory name should not matter (mine is named differently for example). Renaming the base directory *after* cloning (instead of using git clone foo dir-name) can sometimes confuse git, if that might be the problem. In any case, we are unable to reproduce this so if you could provide exact reproductions steps we can update the guide. Your git version may be useful as well. Cheers, Edvard 2017-07-09 22:35 GMT+02:00 Wolfgang Jeltsch : > Hi, Edvard! > > I generally followed the instructions on > > https://github.com/tweag/ghc/tree/linear-types#building-from-source , > > but when running > > git checkout tweag/linear-types , > > I got the following error message: > > > fatal: Not a git repository: ${BASEDIR}/ghc/.git/modules/. > arc-linters/arcanist-external-json-linter > > I guess this is because my local directory is not named “ghc”, but “ghc- > linear”. In my opinion, the repository should not assume that a local > copy of it resides in a directory of a certain name. Is this a GHC issue > or an issue with your linear-types branch? > > All the best, > Wolfgang > > Am Mittwoch, den 05.07.2017, 16:20 +0000 schrieb Edvard Hübinette: > > Hi Wolfgang, > > > > I've put together a small README for getting this up and running (both > > for using stack with pre-built Docker images, and from source). It can > > be found in the repository here: https://github.com/tweag/ghc/tree/lin > > ear-types. > > > > Hope this will help! > > > > Cheers, > > Edvard Hübinette > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wolfgang-it at jeltsch.info Mon Jul 10 11:41:51 2017 From: wolfgang-it at jeltsch.info (Wolfgang Jeltsch) Date: Mon, 10 Jul 2017 14:41:51 +0300 Subject: Which stable GHC release is expected to have support for linear types? In-Reply-To: References: <1499632546.2497.258.camel@jeltsch.info> Message-ID: <1499686911.2497.272.camel@jeltsch.info> Hi, Edvard! I renamed the local directory after cloning. If Git really cannot deal with this, then this is yet another reason for preferring darcs over Git. Unfortunately, it would be hard to reproduce this problem, since I took slightly different steps before incorporating the linear-types branch, as I did not yet know about the documentation on getting the linear- types branch at that time. All the best, Wolfgang Am Montag, den 10.07.2017, 11:22 +0200 schrieb Edvard Hübinette: > Hi Wolfgang,  > > the directory name should not matter (mine is named differently for > example). Renaming the base directory after cloning (instead of using > git clone foo dir-name) can sometimes confuse git, if that might be > the problem. > > In any case, we are unable to reproduce this so if you could provide > exact reproductions steps we can update the guide. Your git version > may be useful as well. > > Cheers, > Edvard > > 2017-07-09 22:35 GMT+02:00 Wolfgang Jeltsch > : > > Hi, Edvard! > > > > I generally followed the instructions on > > > >     https://github.com/tweag/ghc/tree/linear-types#building-from-sou > > rce  , > > > > but when running > > > >     git checkout tweag/linear-types  , > > > > I got the following error message: > > > > > fatal: Not a git repository: ${BASEDIR}/ghc/.git/modules/.arc- > > linters/arcanist-external-json-linter > > > > I guess this is because my local directory is not named “ghc”, but > > “ghc- > > linear”. In my opinion, the repository should not assume that a > > local > > copy of it resides in a directory of a certain name. Is this a GHC > > issue > > or an issue with your linear-types branch? > > > > All the best, > > Wolfgang > > > > Am Mittwoch, den 05.07.2017, 16:20 +0000 schrieb Edvard Hübinette: > > > Hi Wolfgang,  > > > > > > I've put together a small README for getting this up and running > > (both > > > for using stack with pre-built Docker images, and from source). It > > can > > > be found in the repository here: https://github.com/tweag/ghc/tree > > /lin > > > ear-types. > > > > > > Hope this will help! > > > > > > Cheers, > > > Edvard Hübinette > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From svenpanne at gmail.com Mon Jul 10 14:31:52 2017 From: svenpanne at gmail.com (Sven Panne) Date: Mon, 10 Jul 2017 16:31:52 +0200 Subject: Which stable GHC release is expected to have support for linear types? In-Reply-To: <1499686911.2497.272.camel@jeltsch.info> References: <1499632546.2497.258.camel@jeltsch.info> <1499686911.2497.272.camel@jeltsch.info> Message-ID: 2017-07-10 13:41 GMT+02:00 Wolfgang Jeltsch : > I renamed the local directory after cloning. If Git really cannot deal > with this, then this is yet another reason for preferring darcs over Git. > [...] > You can happily move around any cloned repository, Git has absolutely no problem with that. What often breaks is some imperfect tooling on top of Git itself, which might be the case here. Just my 2c, S. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wolfgang-it at jeltsch.info Mon Jul 10 15:55:46 2017 From: wolfgang-it at jeltsch.info (Wolfgang Jeltsch) Date: Mon, 10 Jul 2017 18:55:46 +0300 Subject: Which stable GHC release is expected to have support for linear types? In-Reply-To: References: Message-ID: <1499702146.2497.294.camel@jeltsch.info> Hi! I was finally able to get GHC with the linear types extension running. There is one bit missing though: How do I enable this extension? Apparently there is no extension whose name starts with “Linear”, and when quickly skimming through the list of extensions available for auto- completion in GHCi, I could not find anything related to linear types. All the best, Wolfgang Am Mittwoch, den 05.07.2017, 16:20 +0000 schrieb Edvard Hübinette: > Hi Wolfgang,  > > I've put together a small README for getting this up and running (both > for using stack with pre-built Docker images, and from source). It can > be found in the repository here: https://github.com/tweag/ghc/tree/lin > ear-types. > > Hope this will help! > > Cheers, > Edvard Hübinette -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Tue Jul 11 06:39:59 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 11 Jul 2017 08:39:59 +0200 Subject: Which stable GHC release is expected to have support for linear types? In-Reply-To: References: <1499632546.2497.258.camel@jeltsch.info> <1499686911.2497.272.camel@jeltsch.info> Message-ID: <1499755199.1162.3.camel@joachim-breitner.de> Hi, Am Montag, den 10.07.2017, 16:31 +0200 schrieb Sven Panne: > 2017-07-10 13:41 GMT+02:00 Wolfgang Jeltsch >: > > I renamed the local directory after cloning. If Git really cannot > > deal with this, then this is yet another reason for preferring > > darcs over Git. [...] > > > > You can happily move around any cloned repository, Git has absolutely > no problem with that. What often breaks is some imperfect tooling on > top of Git itself, which might be the case here. I found that this is not true for git modules, which can be very annoying; see https://stackoverflow.com/a/11298947/946226 (Of course, in some sense, git modules are “imperfect tooling on top of Git”, so you are not wrong). Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From svenpanne at gmail.com Tue Jul 11 07:30:31 2017 From: svenpanne at gmail.com (Sven Panne) Date: Tue, 11 Jul 2017 09:30:31 +0200 Subject: Which stable GHC release is expected to have support for linear types? In-Reply-To: <1499755199.1162.3.camel@joachim-breitner.de> References: <1499632546.2497.258.camel@jeltsch.info> <1499686911.2497.272.camel@jeltsch.info> <1499755199.1162.3.camel@joachim-breitner.de> Message-ID: 2017-07-11 8:39 GMT+02:00 Joachim Breitner : > Am Montag, den 10.07.2017, 16:31 +0200 schrieb Sven Panne: > > You can happily move around any cloned repository, Git has absolutely > > no problem with that. What often breaks is some imperfect tooling on > > top of Git itself, which might be the case here. > > I found that this is not true for git modules, which can be very > annoying; see https://stackoverflow.com/a/11298947/946226 [...] This is only true for repos created with ancient Git versions. With newer versions (>= 1.7.10) there is no problem, see e.g. https://stackoverflow.com/questions/17568543/git-add-doesnt-work/17747571#17747571 . -------------- next part -------------- An HTML attachment was scrubbed... URL: From iavor.diatchki at gmail.com Tue Jul 11 16:07:59 2017 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Tue, 11 Jul 2017 09:07:59 -0700 Subject: Building GHC reference manual? Message-ID: Hello, is it possible to build just the HTML for the GHC reference manual, without building the whole of GHC, and if so how do I do it? -Iavor -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Jul 11 17:24:54 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 11 Jul 2017 17:24:54 +0000 Subject: Simon's (lack of) input Message-ID: Friends My GHC inbox has grown to alarming proportions. I try to keep abreast of tickets where I think I have something substantial contribute, and generally succeed, but I've been failing badly in the last few weeks because of a storm of other commitments. I'll get back to it, but probably not before my summer holiday 3-17 August. Meanwhile if you are stalled awaiting input from me, please feel free to ping me about it. Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Tue Jul 11 18:50:39 2017 From: ben at smart-cactus.org (Ben Gamari) Date: Tue, 11 Jul 2017 14:50:39 -0400 Subject: Building GHC reference manual? In-Reply-To: References: Message-ID: <87r2xmu7sw.fsf@ben-laptop.smart-cactus.org> Iavor Diatchki writes: > Hello, > > is it possible to build just the HTML for the GHC reference manual, without > building the whole of GHC, and if so how do I do it? > It is. Just run `make html` from the source root. Note, however, that BUILD_SPHINX_HTML must be set to YES for this to work. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From harendra.kumar at gmail.com Tue Jul 11 22:46:58 2017 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Wed, 12 Jul 2017 04:16:58 +0530 Subject: Building GHC reference manual? In-Reply-To: References: Message-ID: Its well documented here: https://ghc.haskell.org/trac/ghc/wiki/Building/Docs. -harendra On 11 July 2017 at 21:37, Iavor Diatchki wrote: > Hello, > > is it possible to build just the HTML for the GHC reference manual, > without building the whole of GHC, and if so how do I do it? > > -Iavor > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at nh2.me Wed Jul 12 12:37:06 2017 From: mail at nh2.me (=?UTF-8?Q?Niklas_Hamb=c3=bcchen?=) Date: Wed, 12 Jul 2017 14:37:06 +0200 Subject: Bringing back #ghc IRC logging Message-ID: Hi, as you may have noticed, #ghc IRC logging has been broken for months (though the channel topic still says "Logs: http://ircbrowse.net/ghc"). Logs being unavailable is bad because many problems and topics that were googleable before are no longer googleable. We have discussed in the last 2 days on #ghc whether we should just join #ghc with a 0-effort-on-our-side public logging service like botbot.me. This one in particular doesn't have the best UI but I found it to be very googleable, and many open-source projects use it successfully. Is anybody opposed to this? Niklas From ben at well-typed.com Wed Jul 12 13:25:29 2017 From: ben at well-typed.com (Ben Gamari) Date: Wed, 12 Jul 2017 09:25:29 -0400 Subject: Trac down for a bit Message-ID: <87mv89u6ra.fsf@ben-laptop.smart-cactus.org> Hello everyone, Sorry for the interruption but Trac is having some trouble at the moment. I'm actively working on restoring service and will let you know when things are back to normal. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at well-typed.com Wed Jul 12 13:43:05 2017 From: ben at well-typed.com (Ben Gamari) Date: Wed, 12 Jul 2017 09:43:05 -0400 Subject: Trac down for a bit In-Reply-To: <87mv89u6ra.fsf@ben-laptop.smart-cactus.org> References: <87mv89u6ra.fsf@ben-laptop.smart-cactus.org> Message-ID: <87k23du5xy.fsf@ben-laptop.smart-cactus.org> Ben Gamari writes: > Hello everyone, > > Sorry for the interruption but Trac is having some trouble at the > moment. I'm actively working on restoring service and will let you know > when things are back to normal. I believe things should now be back to normal. As always, let me know if you encounter trouble. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at smart-cactus.org Wed Jul 12 15:29:32 2017 From: ben at smart-cactus.org (Ben Gamari) Date: Wed, 12 Jul 2017 11:29:32 -0400 Subject: Bringing back #ghc IRC logging In-Reply-To: References: Message-ID: <87d195u10j.fsf@ben-laptop.smart-cactus.org> Niklas Hambüchen writes: > Hi, > > as you may have noticed, #ghc IRC logging has been broken for months > (though the channel topic still says "Logs: http://ircbrowse.net/ghc"). > I am very much in favor of doing something about this. Unfortunately, Chris Done stepped back from ircbrowse.net around the time that #ghc started using it for logging. Moving to a third-party service like botbot.me sounds quite reasonable to m.e Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From wolfgang-it at jeltsch.info Wed Jul 12 20:11:02 2017 From: wolfgang-it at jeltsch.info (Wolfgang Jeltsch) Date: Wed, 12 Jul 2017 23:11:02 +0300 Subject: Which stable GHC release is expected to have support for linear types? In-Reply-To: <1499702146.2497.294.camel@jeltsch.info> References: <1499702146.2497.294.camel@jeltsch.info> Message-ID: <1499890262.12635.17.camel@jeltsch.info> Hi! I think I figured it out meanwhile: The linear types extension is enabled all the time. I had thought about this possibility already, but then concluded that this was not the case, since types of the form a -o b were not supported. However, when looking at the diffs, I discovered that at the moment, only the Unicode syntax a ⊸ b is understood. All the best, Wolfgang Am Montag, den 10.07.2017, 18:55 +0300 schrieb Wolfgang Jeltsch: > Hi! > > I was finally able to get GHC with the linear types extension running. > There is one bit missing though: How do I enable this extension? > Apparently there is no extension whose name starts with “Linear”, and > when quickly skimming through the list of extensions available for > auto-completion in GHCi, I could not find anything related to linear > types. > > All the best, > Wolfgang > > Am Mittwoch, den 05.07.2017, 16:20 +0000 schrieb Edvard Hübinette: > > Hi Wolfgang,  > > > > I've put together a small README for getting this up and running > > (both for using stack with pre-built Docker images, and from > > source). It can be found in the repository here: https://github.com/ > > tweag/ghc/tree/linear-types. > > > > Hope this will help! > > > > Cheers, > > Edvard Hübinette > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Wed Jul 12 20:15:41 2017 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 12 Jul 2017 16:15:41 -0400 Subject: Which stable GHC release is expected to have support for linear types? In-Reply-To: <1499890262.12635.17.camel@jeltsch.info> References: <1499702146.2497.294.camel@jeltsch.info> <1499890262.12635.17.camel@jeltsch.info> Message-ID: On Wed, Jul 12, 2017 at 4:11 PM, Wolfgang Jeltsch wrote: > I had thought about this possibility already, but then concluded that this > was not the case, since types of the form a -o b were not supported. > However, when looking at the diffs, I discovered that at the moment, only > the Unicode syntax a ⊸ b is understood. > "-o" is going to give the lexer fits. Come up with a purely symbolic version. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From wolfgang-it at jeltsch.info Wed Jul 12 20:47:45 2017 From: wolfgang-it at jeltsch.info (Wolfgang Jeltsch) Date: Wed, 12 Jul 2017 23:47:45 +0300 Subject: Which stable GHC release is expected to have support for linear types? In-Reply-To: References: <1499702146.2497.294.camel@jeltsch.info> <1499890262.12635.17.camel@jeltsch.info> Message-ID: <1499892465.12635.34.camel@jeltsch.info> Am Mittwoch, den 12.07.2017, 16:15 -0400 schrieb Brandon Allbery: > On Wed, Jul 12, 2017 at 4:11 PM, Wolfgang Jeltsch > .info> wrote: > > I had thought about this possibility already, but then concluded > > that this was not the case, since types of the form a -o b were not > > supported. However, when looking at the diffs, I discovered that at > > the moment, only the Unicode syntax a ⊸ b is understood. > "-o" is going to give the lexer fits. Come up with a purely symbolic > version. It was not me who invented the syntax “-o”. Actually, I do not like it either. While it nicely resembles the lollipop (⊸), implementing it requires stealing syntax. This syntax stealing is worse than the syntax stealing of, say, hierarchical modules. With hierarchical modules in place, you have to use spaces in function composition, but this is reasonable anyhow. However, with “-o” as a lollipop alternative in place, you have to write the negation of o with a space, which is awkward. Alternatives for “-o” I can think of are “~>”, “-:”, and “-*”, the latter resembling the magic wand operators in the logic of bunched implications and in separation logic, which are similar to the lollipop in linear logic. All the best, Wolfgang -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Thu Jul 13 09:03:44 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 13 Jul 2017 11:03:44 +0200 Subject: Which stable GHC release is expected to have support for linear types? In-Reply-To: <1499892465.12635.34.camel@jeltsch.info> References: <1499702146.2497.294.camel@jeltsch.info> <1499890262.12635.17.camel@jeltsch.info> <1499892465.12635.34.camel@jeltsch.info> Message-ID: <1499936624.25802.6.camel@joachim-breitner.de> Hi, Am Mittwoch, den 12.07.2017, 23:47 +0300 schrieb Wolfgang Jeltsch: > Alternatives for “-o” I can think of are “~>”, “-:”, and “-*”, the > latter resembling the magic wand operators in the logic of bunched > implications and in separation logic, which are similar to the > lollipop in linear logic. how about -<> ? Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From wolfgang-it at jeltsch.info Thu Jul 13 22:31:50 2017 From: wolfgang-it at jeltsch.info (Wolfgang Jeltsch) Date: Fri, 14 Jul 2017 01:31:50 +0300 Subject: Which stable GHC release is expected to have support for linear types? In-Reply-To: <1499936624.25802.6.camel@joachim-breitner.de> References: <1499702146.2497.294.camel@jeltsch.info> <1499890262.12635.17.camel@jeltsch.info> <1499892465.12635.34.camel@jeltsch.info> <1499936624.25802.6.camel@joachim-breitner.de> Message-ID: <1499985110.12635.68.camel@jeltsch.info> Am Donnerstag, den 13.07.2017, 11:03 +0200 schrieb Joachim Breitner: > Am Mittwoch, den 12.07.2017, 23:47 +0300 schrieb Wolfgang Jeltsch: > > Alternatives for “-o” I can think of are “~>”, “-:”, and “-*”, the > > latter resembling the magic wand operators in the logic of bunched > > implications and in separation logic, which are similar to the > > lollipop in linear logic. > > how about -<> ? Hmm, the “<>” part seems to be a bit heavy compared to the little “-”. All the best, Wolfgang From eleventynine at gmail.com Thu Jul 13 23:26:35 2017 From: eleventynine at gmail.com (Mike Ledger) Date: Fri, 14 Jul 2017 09:26:35 +1000 Subject: Which stable GHC release is expected to have support for linear types? In-Reply-To: <1499985110.12635.68.camel@jeltsch.info> References: <1499702146.2497.294.camel@jeltsch.info> <1499890262.12635.17.camel@jeltsch.info> <1499892465.12635.34.camel@jeltsch.info> <1499936624.25802.6.camel@joachim-breitner.de> <1499985110.12635.68.camel@jeltsch.info> Message-ID: How about: -+ It almost looks arrow like if you squint, and have a font that lines up the horizontal lines. Cheers, Mike On 14 Jul 2017 08:32, "Wolfgang Jeltsch" wrote: Am Donnerstag, den 13.07.2017, 11:03 +0200 schrieb Joachim Breitner: > Am Mittwoch, den 12.07.2017, 23:47 +0300 schrieb Wolfgang Jeltsch: > > Alternatives for “-o” I can think of are “~>”, “-:”, and “-*”, the > > latter resembling the magic wand operators in the logic of bunched > > implications and in separation logic, which are similar to the > > lollipop in linear logic. > > how about -<> ? Hmm, the “<>” part seems to be a bit heavy compared to the little “-”. All the best, Wolfgang _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From wolfgang-it at jeltsch.info Thu Jul 13 23:48:59 2017 From: wolfgang-it at jeltsch.info (Wolfgang Jeltsch) Date: Fri, 14 Jul 2017 02:48:59 +0300 Subject: Which stable GHC release is expected to have support for linear types? In-Reply-To: References: <1499702146.2497.294.camel@jeltsch.info> <1499890262.12635.17.camel@jeltsch.info> <1499892465.12635.34.camel@jeltsch.info> <1499936624.25802.6.camel@joachim-breitner.de> <1499985110.12635.68.camel@jeltsch.info> Message-ID: <1499989739.12635.80.camel@jeltsch.info> Am Freitag, den 14.07.2017, 09:26 +1000 schrieb Mike Ledger: > How about: -+ > > It almost looks arrow like if you squint, and have a font that lines > up the horizontal lines. Interesting idea. Seems pretty good to me. It does not only look arrow- like, but also similar to the lollipop (⊸). Let’s try it out: > fmap :: Functor f => (a -+ b) -> f a -+ f b Yes, this looks quite nice. Let’s compare it to the Unicode version: > fmap ∷ Functor f ⇒ (a ⊸ b) → (f a ⊸ f b) They look similar indeed. 😉 All the best, Wolfgang -------------- next part -------------- An HTML attachment was scrubbed... URL: From spam at scientician.net Fri Jul 14 04:42:12 2017 From: spam at scientician.net (Bardur Arantsson) Date: Fri, 14 Jul 2017 06:42:12 +0200 Subject: Which stable GHC release is expected to have support for linear types? In-Reply-To: References: <1499702146.2497.294.camel@jeltsch.info> <1499890262.12635.17.camel@jeltsch.info> <1499892465.12635.34.camel@jeltsch.info> <1499936624.25802.6.camel@joachim-breitner.de> <1499985110.12635.68.camel@jeltsch.info> Message-ID: On 2017-07-14 01:26, Mike Ledger wrote: > How about: -+ > > It almost looks arrow like if you squint, and have a font that lines up > the horizontal lines. > This may play havoc with programming fonts with ligatures where it might be rendered as a single ± symbol. (I haven't tested any of the fonts, I'm just saying it _could_ be an issue.) Regards, From rae at cs.brynmawr.edu Fri Jul 14 12:44:14 2017 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Fri, 14 Jul 2017 08:44:14 -0400 Subject: GHCi tests hanging on Mac Message-ID: <20192631-DD9B-4533-88EE-0041698421BD@cs.brynmawr.edu> Hi devs, Some GHCi tests (but far from all!) hang on my Mac. I can't reproduce this behavior outside the testsuite driver, so I think it's the Python code, not the Haskell. Failing tests: ghci/prog017/prog017 ghci/scripts/T6018ghcifail ghci/scripts/T6018ghcirnfail And that's it! My Python reports that it's 2.7.13. Any leads to follow? Thanks, Richard From ben at well-typed.com Fri Jul 14 16:14:31 2017 From: ben at well-typed.com (Ben Gamari) Date: Fri, 14 Jul 2017 12:14:31 -0400 Subject: GHCi tests hanging on Mac In-Reply-To: <20192631-DD9B-4533-88EE-0041698421BD@cs.brynmawr.edu> References: <20192631-DD9B-4533-88EE-0041698421BD@cs.brynmawr.edu> Message-ID: <87y3rrro60.fsf@ben-laptop.smart-cactus.org> Richard Eisenberg writes: > Hi devs, > > Some GHCi tests (but far from all!) hang on my Mac. I can't reproduce > this behavior outside the testsuite driver, so I think it's the Python > code, not the Haskell. > > Failing tests: > ghci/prog017/prog017 > ghci/scripts/T6018ghcifail > ghci/scripts/T6018ghcirnfail > > And that's it! My Python reports that it's 2.7.13. > Hmm, well that is concerning. As far as I can tell the only thing that these tests share is that their scripts are relatively long. However, they aren't unique in this regard; if this were the cause I would have also expected, for instance, T2182ghci and T11524a to fail as well. Is it really always this set of tests that fail? Do they fail reliably? Are you certain you are running the test in the same way that the testsuite driver is (specifically, piping the script to stdin of the ghci process)? I just looked at the driver implementation and it seems to me that it could be simplified a bit. Does D3735 help? It's admittedly a stab in the dark, but Python has surprised me in the past. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From wolfgang-it at jeltsch.info Fri Jul 14 19:59:13 2017 From: wolfgang-it at jeltsch.info (Wolfgang Jeltsch) Date: Fri, 14 Jul 2017 22:59:13 +0300 Subject: Which stable GHC release is expected to have support for linear types? In-Reply-To: References: <1499702146.2497.294.camel@jeltsch.info> <1499890262.12635.17.camel@jeltsch.info> <1499892465.12635.34.camel@jeltsch.info> <1499936624.25802.6.camel@joachim-breitner.de> <1499985110.12635.68.camel@jeltsch.info> Message-ID: <1500062353.12635.99.camel@jeltsch.info> Am Freitag, den 14.07.2017, 06:42 +0200 schrieb Bardur Arantsson: > On 2017-07-14 01:26, Mike Ledger wrote: > > How about: -+ > > > > It almost looks arrow like if you squint, and have a font that lines > > up the horizontal lines. > > This may play havoc with programming fonts with ligatures where it > might be rendered as a single ± symbol. > > (I haven't tested any of the fonts, I'm just saying it _could_ be an > issue.) I would expect such fonts to translate “+-”, not “-+”, into “±”. All the best, Wolfgang From spam at scientician.net Sat Jul 15 08:57:19 2017 From: spam at scientician.net (Bardur Arantsson) Date: Sat, 15 Jul 2017 10:57:19 +0200 Subject: Which stable GHC release is expected to have support for linear types? In-Reply-To: <1500062353.12635.99.camel@jeltsch.info> References: <1499702146.2497.294.camel@jeltsch.info> <1499890262.12635.17.camel@jeltsch.info> <1499892465.12635.34.camel@jeltsch.info> <1499936624.25802.6.camel@joachim-breitner.de> <1499985110.12635.68.camel@jeltsch.info> <1500062353.12635.99.camel@jeltsch.info> Message-ID: On 2017-07-14 21:59, Wolfgang Jeltsch wrote: > Am Freitag, den 14.07.2017, 06:42 +0200 schrieb Bardur Arantsson: >> On 2017-07-14 01:26, Mike Ledger wrote: >>> How about: -+ >>> >>> It almost looks arrow like if you squint, and have a font that lines >>> up the horizontal lines. >> >> This may play havoc with programming fonts with ligatures where it >> might be rendered as a single ± symbol. >> >> (I haven't tested any of the fonts, I'm just saying it _could_ be an >> issue.) > > I would expect such fonts to translate “+-”, not “-+”, into “±”. > Maybe, but it seems a bit fragile to me... What about -*? At least there's no ambiguity there. Regards, From allbery.b at gmail.com Sat Jul 15 12:36:54 2017 From: allbery.b at gmail.com (Brandon Allbery) Date: Sat, 15 Jul 2017 08:36:54 -0400 Subject: Which stable GHC release is expected to have support for linear types? In-Reply-To: References: <1499702146.2497.294.camel@jeltsch.info> <1499890262.12635.17.camel@jeltsch.info> <1499892465.12635.34.camel@jeltsch.info> <1499936624.25802.6.camel@joachim-breitner.de> <1499985110.12635.68.camel@jeltsch.info> <1500062353.12635.99.camel@jeltsch.info> Message-ID: On Sat, Jul 15, 2017 at 4:57 AM, Bardur Arantsson wrote: > Maybe, but it seems a bit fragile to me... > > What about -*? At least there's no ambiguity there. > As previously stated: "Alternatives for “-o” I can think of are “~>”, “-:”, and “-*”, the latter resembling the magic wand operators in the logic of bunched implications and in separation logic, which are similar to the lollipop in linear logic." -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From wolfgang-it at jeltsch.info Sat Jul 15 21:29:40 2017 From: wolfgang-it at jeltsch.info (Wolfgang Jeltsch) Date: Sun, 16 Jul 2017 00:29:40 +0300 Subject: Which stable GHC release is expected to have support for linear types? In-Reply-To: References: <1499702146.2497.294.camel@jeltsch.info> <1499890262.12635.17.camel@jeltsch.info> <1499892465.12635.34.camel@jeltsch.info> <1499936624.25802.6.camel@joachim-breitner.de> <1499985110.12635.68.camel@jeltsch.info> <1500062353.12635.99.camel@jeltsch.info> Message-ID: <1500154180.2422.55.camel@jeltsch.info> Am Samstag, den 15.07.2017, 10:57 +0200 schrieb Bardur Arantsson: > On 2017-07-14 21:59, Wolfgang Jeltsch wrote: > > Am Freitag, den 14.07.2017, 06:42 +0200 schrieb Bardur Arantsson: > > > On 2017-07-14 01:26, Mike Ledger wrote: > > > > How about: -+ > > > > > > > > It almost looks arrow like if you squint, and have a font that > > > > lines up the horizontal lines. > > > > > > This may play havoc with programming fonts with ligatures where it > > > might be rendered as a single ± symbol. > > >  > > I would expect such fonts to translate “+-”, not “-+”, into “±”. > > > Maybe, but it seems a bit fragile to me... I would not care too much about such fonts. In my opinion, the natural way is to generate ± from +-, not from -+. Since there is the option to generate ± from +-, there is no need to additionally generate it from -+. Font designers could just stop doing this if there are doing it at all at the moment. > What about -*? At least there's no ambiguity there. The problem with -* is that the star is typically higher than the -, so that -* looks a bit awkward. I think, using -+ is a pretty good idea. All the best, Wolfgang From rae at cs.brynmawr.edu Tue Jul 18 12:27:10 2017 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Tue, 18 Jul 2017 08:27:10 -0400 Subject: Proposed: Language.Haskell.TH.Internal Message-ID: Hi devs, This is a brief proposal for an internal, non-user-facing restructuring of the implementation of Template Haskell. It's here (instead of at ghc-proposals) because it's not user-facing. When a user writes a TH quote [| foo bar baz |], GHC must desugar that into some Core code that builds a Q Exp. This is currently done by calling functions in Language.Haskell.TH.Lib, which is capable of building all the TH abstract syntax. However, many end-users of TH *also* import Language.Haskell.TH.Lib and use its functions. This means that, as the Haskell AST evolves, we can't reasonably evolve this Lib module, as it breaks user code. (There is a requisite amount of churn in TH, but we try to avoid gratuitous changes in Lib.) This has bitten in the past when we have, say, changed the representation of type families to accommodate closed type families, and it's biting now as we (ahem, Ryan Scott) are trying to merge types and kinds in TH. I thus propose a new module Language.Haskell.TH.Internal. This will start out as a slimmed-down copy of Lib (slimmed-down because Lib already has a bunch of now-disused functions) but may evolve independently. Desugaring quotes will go via this new Internal module, and we will have no qualms about changing its interface, as it's Internal. What do we think? Ryan has already implemented this idea in D3751. Pros: - Flexibility - Separation between user-facing interface and internal interface Cons: - More stuff - We already break the TH API with every release; maybe it's not so bad to break more of it. Thanks, Richard From alan.zimm at gmail.com Tue Jul 18 12:40:36 2017 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Tue, 18 Jul 2017 14:40:36 +0200 Subject: Proposed: Language.Haskell.TH.Internal In-Reply-To: References: Message-ID: This can serve as a starting point for the Trees that Grow implementation too, I understand Shayan Najd is intending to eventually harmonise the hsSyn AST and the TH one. Alan On 18 July 2017 at 14:27, Richard Eisenberg wrote: > Hi devs, > > This is a brief proposal for an internal, non-user-facing restructuring of > the implementation of Template Haskell. It's here (instead of at > ghc-proposals) because it's not user-facing. > > When a user writes a TH quote [| foo bar baz |], GHC must desugar that > into some Core code that builds a Q Exp. This is currently done by calling > functions in Language.Haskell.TH.Lib, which is capable of building all the > TH abstract syntax. However, many end-users of TH *also* import > Language.Haskell.TH.Lib and use its functions. This means that, as the > Haskell AST evolves, we can't reasonably evolve this Lib module, as it > breaks user code. (There is a requisite amount of churn in TH, but we try > to avoid gratuitous changes in Lib.) This has bitten in the past when we > have, say, changed the representation of type families to accommodate > closed type families, and it's biting now as we (ahem, Ryan Scott) are > trying to merge types and kinds in TH. > > I thus propose a new module Language.Haskell.TH.Internal. This will start > out as a slimmed-down copy of Lib (slimmed-down because Lib already has a > bunch of now-disused functions) but may evolve independently. Desugaring > quotes will go via this new Internal module, and we will have no qualms > about changing its interface, as it's Internal. > > What do we think? Ryan has already implemented this idea in D3751. > > Pros: > - Flexibility > - Separation between user-facing interface and internal interface > > Cons: > - More stuff > - We already break the TH API with every release; maybe it's not so bad > to break more of it. > > Thanks, > Richard > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From conal at conal.net Tue Jul 18 15:34:58 2017 From: conal at conal.net (Conal Elliott) Date: Tue, 18 Jul 2017 08:34:58 -0700 Subject: Repeated computations under a lambda Message-ID: I'm seeing what looks like repeated computation under a lambda with `-O` and `-O2`. The following definition: > exampleC :: Double -> Double -> Double > exampleC = \ t -> let s = sin t in \ x -> x + s yields this Core: > -- RHS size: {terms: 13, types: 6, coercions: 0} > exampleC :: Double -> Double -> Double > exampleC = > \ (t_afI6 :: Double) (eta_B1 :: Double) -> > case eta_B1 of _ { D# x_aj5c -> > case t_afI6 of _ { D# x1_aj5l -> > D# (+## x_aj5c (sinDouble# x1_aj5l)) > } > } The `sinDouble#` here depends only on `t_afI6` (`t`) but still appears under the binding of `eta_B1` (`x`). I'm concerned because many of my uses of such functions involve computations dependent only on `t` (time) but with millions of uses (space) per `t`. (I'm working on a GHC Core plugin (compiling to categories), with one use generating graphics GPU code.) Does the optimization I expected somehow happen later in the compilation pipeline? Are there Core-manipulating functions in GHC that I can use to make it happen earlier (via a `BuiltinRule`, i.e., Core-to-Core function)? Thanks, -- Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgraf1337 at gmail.com Tue Jul 18 16:48:14 2017 From: sgraf1337 at gmail.com (Sebastian Graf) Date: Tue, 18 Jul 2017 18:48:14 +0200 Subject: Repeated computations under a lambda In-Reply-To: References: Message-ID: Hi Conal, so if I understand this right, you'd rather not wanted `exampleC` to be eta-expanded (or the binding of `s` to be floated into the lambda)? Or is it that you want CSE to find out that you always supply the same `t` as the first argument and share the partial application and thus the work of computing `s`? If it's the former: GHC doesn't normally do this, unless it has found out that no sharing (of work done to evaluate `s`) would be lost through eta-expansion. This is the case when `exampleC` is always called with two arguments, so that no binding of `s` is shared, for example. Could you maybe post a complete module/expression representative of all uses of `exampleC`? If it's the latter, I'm afraid I can't really help, but surely someone else can. Cheers, Sebastian On Tue, Jul 18, 2017 at 5:34 PM, Conal Elliott wrote: > I'm seeing what looks like repeated computation under a lambda with `-O` > and `-O2`. The following definition: > > > exampleC :: Double -> Double -> Double > > exampleC = \ t -> let s = sin t in \ x -> x + s > > yields this Core: > > > -- RHS size: {terms: 13, types: 6, coercions: 0} > > exampleC :: Double -> Double -> Double > > exampleC = > > \ (t_afI6 :: Double) (eta_B1 :: Double) -> > > case eta_B1 of _ { D# x_aj5c -> > > case t_afI6 of _ { D# x1_aj5l -> > > D# (+## x_aj5c (sinDouble# x1_aj5l)) > > } > > } > > The `sinDouble#` here depends only on `t_afI6` (`t`) but still appears > under the binding of `eta_B1` (`x`). > > I'm concerned because many of my uses of such functions involve > computations dependent only on `t` (time) but with millions of uses (space) > per `t`. (I'm working on a GHC Core plugin (compiling to categories), with > one use generating graphics GPU code.) > > Does the optimization I expected somehow happen later in the compilation > pipeline? > > Are there Core-manipulating functions in GHC that I can use to make it > happen earlier (via a `BuiltinRule`, i.e., Core-to-Core function)? > > Thanks, > -- Conal > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Tue Jul 18 19:08:14 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 18 Jul 2017 15:08:14 -0400 Subject: Repeated computations under a lambda In-Reply-To: References: Message-ID: <1500404894.20659.6.camel@joachim-breitner.de> Hi, Am Dienstag, den 18.07.2017, 08:34 -0700 schrieb Conal Elliott: > I'm seeing what looks like repeated computation under a lambda with > `-O` and `-O2`. The following definition: > > > exampleC :: Double -> Double -> Double > > exampleC = \ t -> let s = sin t in \ x -> x + s > > yields this Core: > > > -- RHS size: {terms: 13, types: 6, coercions: 0} > > exampleC :: Double -> Double -> Double > > exampleC = > >   \ (t_afI6 :: Double) (eta_B1 :: Double) -> > >     case eta_B1 of _ { D# x_aj5c -> > >     case t_afI6 of _ { D# x1_aj5l -> > >     D# (+## x_aj5c (sinDouble# x1_aj5l)) > >     } > >     } ghc -O -dverbose-core2core shows you that the problem is this phase: ==================== Simplifier ====================   Max iterations = 4   SimplMode {Phase = 2 [main],              inline,              rules,              eta-expand,              case-of-case} It does not happen with -fno-do-lambda-eta-expansion (but you’d lose in other parts.) > I'm concerned because many of my uses of such functions involve > computations dependent only on `t` (time) but with millions of uses > (space) per `t`. (I'm working on a GHC Core plugin (compiling to > categories), with one use generating graphics GPU code.) Did you measure whether this really is a problem? The benefits of not dealing with dynamically allocated functions might outweigh the cost of recalculating sin. Greetings, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From simonpj at microsoft.com Tue Jul 18 21:40:53 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 18 Jul 2017 21:40:53 +0000 Subject: Proposed: Language.Haskell.TH.Internal In-Reply-To: References: Message-ID: OK with me, provided we document the thinking so that users understand the architecture. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Richard | Eisenberg | Sent: 18 July 2017 13:27 | To: GHC developers | Cc: Ryan Scott | Subject: Proposed: Language.Haskell.TH.Internal | | Hi devs, | | This is a brief proposal for an internal, non-user-facing restructuring | of the implementation of Template Haskell. It's here (instead of at ghc- | proposals) because it's not user-facing. | | When a user writes a TH quote [| foo bar baz |], GHC must desugar that | into some Core code that builds a Q Exp. This is currently done by | calling functions in Language.Haskell.TH.Lib, which is capable of | building all the TH abstract syntax. However, many end-users of TH *also* | import Language.Haskell.TH.Lib and use its functions. This means that, as | the Haskell AST evolves, we can't reasonably evolve this Lib module, as | it breaks user code. (There is a requisite amount of churn in TH, but we | try to avoid gratuitous changes in Lib.) This has bitten in the past when | we have, say, changed the representation of type families to accommodate | closed type families, and it's biting now as we (ahem, Ryan Scott) are | trying to merge types and kinds in TH. | | I thus propose a new module Language.Haskell.TH.Internal. This will start | out as a slimmed-down copy of Lib (slimmed-down because Lib already has a | bunch of now-disused functions) but may evolve independently. Desugaring | quotes will go via this new Internal module, and we will have no qualms | about changing its interface, as it's Internal. | | What do we think? Ryan has already implemented this idea in D3751. | | Pros: | - Flexibility | - Separation between user-facing interface and internal interface | | Cons: | - More stuff | - We already break the TH API with every release; maybe it's not so bad | to break more of it. | | Thanks, | Richard | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | devs&data=02%7C01%7Csimonpj%40microsoft.com%7Cc77c4285ceef48c4783608d4cdd | 8ab70%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636359777860344686&sda | ta=TxVVdCy2qEpZnbWDiaPOajm14EivqRDTZdIDVVIax3M%3D&reserved=0 From conal at conal.net Tue Jul 18 22:35:32 2017 From: conal at conal.net (Conal Elliott) Date: Tue, 18 Jul 2017 15:35:32 -0700 Subject: Repeated computations under a lambda In-Reply-To: <1500404894.20659.6.camel@joachim-breitner.de> References: <1500404894.20659.6.camel@joachim-breitner.de> Message-ID: Thanks very much for this reply, Joachim. I see that `-fno-do-lambda-eta-expansion` with my example prevents moving the computation under the lambda where it gets repeatedly evaluated. I don't understand what this code motion/substitution has to do with eta-expansion. Is it that the `let` expression itself is eta-expanded? The GHC Users Guide describes this flag as "eta-expand let-bindings to increase their arity", which doesn't seem to fit here, since the `let`-bindings are not function-valued (though the `let` expression is). Thanks also for the suggestion of using `-dverbose-core2core` to see where the unwanted substitution happened. Did you measure whether this really is a problem? The benefits of not > dealing with dynamically allocated functions might outweigh the cost of > recalculating sin. No, I haven't measured. In this case, I'm compiling Haskell to GLSL for execution on a GPU, where the inner lambda will be over space, which means at least one application per pixel, so the computations moved under the inner lambda will be redundantly computed a few millions of times per frame (and much more with anti-aliasing). Instead, I want to move those calculations to once per frame and stored in quickly accessed video memory. As the space-independent computation gets more complex, I expect the saving to grow. Thanks again, -- Conal On Tue, Jul 18, 2017 at 12:08 PM, Joachim Breitner wrote: > Hi, > > > Am Dienstag, den 18.07.2017, 08:34 -0700 schrieb Conal Elliott: > > I'm seeing what looks like repeated computation under a lambda with > > `-O` and `-O2`. The following definition: > > > > > exampleC :: Double -> Double -> Double > > > exampleC = \ t -> let s = sin t in \ x -> x + s > > > > yields this Core: > > > > > -- RHS size: {terms: 13, types: 6, coercions: 0} > > > exampleC :: Double -> Double -> Double > > > exampleC = > > > \ (t_afI6 :: Double) (eta_B1 :: Double) -> > > > case eta_B1 of _ { D# x_aj5c -> > > > case t_afI6 of _ { D# x1_aj5l -> > > > D# (+## x_aj5c (sinDouble# x1_aj5l)) > > > } > > > } > > ghc -O -dverbose-core2core shows you that the problem is this phase: > > ==================== Simplifier ==================== > Max iterations = 4 > SimplMode {Phase = 2 [main], > inline, > rules, > eta-expand, > case-of-case} > > It does not happen with -fno-do-lambda-eta-expansion (but you’d lose in > other parts.) > > > I'm concerned because many of my uses of such functions involve > > computations dependent only on `t` (time) but with millions of uses > > (space) per `t`. (I'm working on a GHC Core plugin (compiling to > > categories), with one use generating graphics GPU code.) > > Did you measure whether this really is a problem? The benefits of not > dealing with dynamically allocated functions might outweigh the cost of > recalculating sin. > > Greetings, > Joachim > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Tue Jul 18 22:44:24 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 18 Jul 2017 18:44:24 -0400 Subject: Repeated computations under a lambda In-Reply-To: References: <1500404894.20659.6.camel@joachim-breitner.de> Message-ID: <1500417864.20659.8.camel@joachim-breitner.de> Hi Conal, Am Dienstag, den 18.07.2017, 15:35 -0700 schrieb Conal Elliott: > Thanks very much for this reply, Joachim. I see that `-fno-do-lambda- > eta-expansion` with my example prevents moving the computation under > the lambda where it gets repeatedly evaluated. I don't understand > what this code motion/substitution has to do with eta-expansion. Is > it that the `let` expression itself is eta-expanded? The GHC Users > Guide describes this flag as "eta-expand let-bindings to increase > their arity", which doesn't seem to fit here, since the `let`- > bindings are not function-valued (though the `let` expression is). In the code exampleC :: Double -> Double -> Double exampleC = \ t -> let s = sin t in \ x -> x + s the exampleC is the bound things that is eta-expanded. Ok, it is a top- level function, but that does not make a big difference. When eta- expanded, it becomes exampleC :: Double -> Double -> Double exampleC = \ t y -> (let s = sin t in \ x -> x + s) y and from then on, usual simplifications kick in to produce exampleC :: Double -> Double -> Double exampleC = \ t y -> let s = sin t in y + s and eventually exampleC :: Double -> Double -> Double exampleC = \ t y -> y + sin t (I ignore the unboxing of Doubles here). > > Did you measure whether this really is a problem? The benefits of not > > dealing with dynamically allocated functions might outweigh the cost of > > recalculating sin. > > No, I haven't measured. In this case, I'm compiling Haskell to GLSL > for execution on a GPU, where the inner lambda will be over space, > which means at least one application per pixel, so the computations > moved under the inner lambda will be redundantly computed a few > millions of times per frame (and much more with anti-aliasing). > Instead, I want to move those calculations to once per frame and > stored in quickly accessed video memory. As the space-independent > computation gets more complex, I expect the saving to grow. Hmm. The problem is that GHC’s optimizer uses a cost-model (in this case: calling an anonymous function is worse than recomputing sind) that does not hold in your case. Besides simply turning off some transformations, I am not sure what best you could do to avoid this… Gruß, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From conal at conal.net Tue Jul 18 22:51:57 2017 From: conal at conal.net (Conal Elliott) Date: Tue, 18 Jul 2017 15:51:57 -0700 Subject: Repeated computations under a lambda In-Reply-To: <1500417864.20659.8.camel@joachim-breitner.de> References: <1500404894.20659.6.camel@joachim-breitner.de> <1500417864.20659.8.camel@joachim-breitner.de> Message-ID: > the exampleC is the bound things that is eta-expanded. Oh! I get it now. Thanks. > The problem is that GHC’s optimizer uses a cost-model [...] that does not hold in your case. Makes sense a well. I'll use `-fno-do-lambda-eta-expansion` for now and see well it works. Thanks very much for these tips. Regards, - Conal On Tue, Jul 18, 2017 at 3:44 PM, Joachim Breitner wrote: > Hi Conal, > > Am Dienstag, den 18.07.2017, 15:35 -0700 schrieb Conal Elliott: > > Thanks very much for this reply, Joachim. I see that `-fno-do-lambda- > > eta-expansion` with my example prevents moving the computation under > > the lambda where it gets repeatedly evaluated. I don't understand > > what this code motion/substitution has to do with eta-expansion. Is > > it that the `let` expression itself is eta-expanded? The GHC Users > > Guide describes this flag as "eta-expand let-bindings to increase > > their arity", which doesn't seem to fit here, since the `let`- > > bindings are not function-valued (though the `let` expression is). > > In the code > > exampleC :: Double -> Double -> Double > exampleC = \ t -> let s = sin t in \ x -> x + s > > the exampleC is the bound things that is eta-expanded. Ok, it is a top- > level function, but that does not make a big difference. When eta- > expanded, it becomes > > exampleC :: Double -> Double -> Double > exampleC = \ t y -> (let s = sin > t in \ x -> x + s) y > > and from then on, usual simplifications kick in to produce > > exampleC :: Double -> Double -> Double > exampleC = \ t y -> let s = sin t in y + s > > and eventually > > exampleC :: Double -> Double -> Double > exampleC = \ t y -> y + sin t > > (I ignore the unboxing of Doubles here). > > > > > Did you measure whether this really is a problem? The benefits of not > > > dealing with dynamically allocated functions might outweigh the cost of > > > recalculating sin. > > > > No, I haven't measured. In this case, I'm compiling Haskell to GLSL > > for execution on a GPU, where the inner lambda will be over space, > > which means at least one application per pixel, so the computations > > moved under the inner lambda will be redundantly computed a few > > millions of times per frame (and much more with anti-aliasing). > > Instead, I want to move those calculations to once per frame and > > stored in quickly accessed video memory. As the space-independent > > computation gets more complex, I expect the saving to grow. > > Hmm. The problem is that GHC’s optimizer uses a cost-model (in this > case: calling an anonymous function is worse than recomputing sind) > that does not hold in your case. Besides simply turning off some > transformations, I am not sure what best you could do to avoid this… > > Gruß, > Joachim > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From conal at conal.net Tue Jul 18 22:55:28 2017 From: conal at conal.net (Conal Elliott) Date: Tue, 18 Jul 2017 15:55:28 -0700 Subject: Repeated computations under a lambda In-Reply-To: References: Message-ID: Hi Sebastian, Thanks for the reply. It's that I don't want `exampleC` to be eta-expanded. Apparently GHC does by default even when doing so moves computation under lambda. I've thought otherwise for a very long time. -- Conal On Tue, Jul 18, 2017 at 9:48 AM, Sebastian Graf wrote: > Hi Conal, > > so if I understand this right, you'd rather not wanted `exampleC` to be > eta-expanded (or the binding of `s` to be floated into the lambda)? > Or is it that you want CSE to find out that you always supply the same `t` > as the first argument and share the partial application and thus the work > of computing `s`? > > If it's the former: GHC doesn't normally do this, unless it has found out > that no sharing (of work done to evaluate `s`) would be lost through > eta-expansion. > This is the case when `exampleC` is always called with two arguments, so > that no binding of `s` is shared, for example. > Could you maybe post a complete module/expression representative of all > uses of `exampleC`? > > If it's the latter, I'm afraid I can't really help, but surely someone > else can. > > Cheers, > Sebastian > > On Tue, Jul 18, 2017 at 5:34 PM, Conal Elliott wrote: > >> I'm seeing what looks like repeated computation under a lambda with `-O` >> and `-O2`. The following definition: >> >> > exampleC :: Double -> Double -> Double >> > exampleC = \ t -> let s = sin t in \ x -> x + s >> >> yields this Core: >> >> > -- RHS size: {terms: 13, types: 6, coercions: 0} >> > exampleC :: Double -> Double -> Double >> > exampleC = >> > \ (t_afI6 :: Double) (eta_B1 :: Double) -> >> > case eta_B1 of _ { D# x_aj5c -> >> > case t_afI6 of _ { D# x1_aj5l -> >> > D# (+## x_aj5c (sinDouble# x1_aj5l)) >> > } >> > } >> >> The `sinDouble#` here depends only on `t_afI6` (`t`) but still appears >> under the binding of `eta_B1` (`x`). >> >> I'm concerned because many of my uses of such functions involve >> computations dependent only on `t` (time) but with millions of uses (space) >> per `t`. (I'm working on a GHC Core plugin (compiling to categories), with >> one use generating graphics GPU code.) >> >> Does the optimization I expected somehow happen later in the compilation >> pipeline? >> >> Are there Core-manipulating functions in GHC that I can use to make it >> happen earlier (via a `BuiltinRule`, i.e., Core-to-Core function)? >> >> Thanks, >> -- Conal >> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at well-typed.com Tue Jul 18 23:52:52 2017 From: david at well-typed.com (David Feuer) Date: Tue, 18 Jul 2017 19:52:52 -0400 Subject: Repeated computations under a lambda In-Reply-To: References: Message-ID: <46902333.sKiuf4kdI3@squirrel> On Tuesday, July 18, 2017 3:55:28 PM EDT Conal Elliott wrote: > Hi Sebastian, > > Thanks for the reply. It's that I don't want `exampleC` to be eta-expanded. > Apparently GHC does by default even when doing so moves computation under > lambda. I've thought otherwise for a very long time. GHC really likes to eta-expand, because that can be very good for allocation, unboxing, and I don't know what else. Do you really need to represent the intermediate result by a *function*? Would it work just to save the Double itself? I suspect you could likely convince GHC to leave it alone. David From conal at conal.net Wed Jul 19 00:01:05 2017 From: conal at conal.net (Conal Elliott) Date: Tue, 18 Jul 2017 17:01:05 -0700 Subject: Repeated computations under a lambda In-Reply-To: <46902333.sKiuf4kdI3@squirrel> References: <46902333.sKiuf4kdI3@squirrel> Message-ID: Here's the code in question, slightly rephrased: > exampleC t = \ x -> x + s where s = sin t I wrote it this way so that `sin t` would be computed once per `t` and reused for each value of `x`. The intermediate result `s` has type `Double`---not a function. Without `-fno-do-lambda-eta-expansion`, phase 2 of `ghc -O` causes the `s = sin t` binding to be moved under the `\ x -> ...`. I've been using this programming style for this purpose for longer than I can remember, and apparently I've been mistaken about its effectiveness at least part of that time. -- Conal On Tue, Jul 18, 2017 at 4:52 PM, David Feuer wrote: > On Tuesday, July 18, 2017 3:55:28 PM EDT Conal Elliott wrote: > > Hi Sebastian, > > > > Thanks for the reply. It's that I don't want `exampleC` to be > eta-expanded. > > Apparently GHC does by default even when doing so moves computation under > > lambda. I've thought otherwise for a very long time. > > GHC really likes to eta-expand, because that can be very good for > allocation, > unboxing, and I don't know what else. Do you really need to represent the > intermediate result by a *function*? Would it work just to save the Double > itself? I suspect you could likely convince GHC to leave it alone. > > David > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Wed Jul 19 01:51:46 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 18 Jul 2017 21:51:46 -0400 Subject: Repeated computations under a lambda In-Reply-To: References: <46902333.sKiuf4kdI3@squirrel> Message-ID: <1500429106.9535.4.camel@joachim-breitner.de> Hi, Am Dienstag, den 18.07.2017, 17:01 -0700 schrieb Conal Elliott: > Here's the code in question, slightly rephrased: > > > exampleC t = \ x -> x + s where s = sin t > > I wrote it this way so that `sin t` would be computed once per `t` > and reused for each value of `x`. The intermediate result `s` has > type `Double`---not a function. Without `-fno-do-lambda-eta- > expansion`, phase 2 of `ghc -O` causes the `s = sin t` binding to be > moved under the `\ x -> ...`. I've been using this programming style > for this purpose for longer than I can remember, and apparently I've > been mistaken about its effectiveness at least part of that time. usually it is very effective. GHC does this transformation not nilly- willy, but only when its heuristics indicate that it is ok, usually because the operation (here sin) is known to be very cheap. If that code would call some unknown function, or allocate memory, then GHC would certainly preserve your intention. Greetings, Joachim -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From simonpj at microsoft.com Wed Jul 19 07:50:20 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 19 Jul 2017 07:50:20 +0000 Subject: Repeated computations under a lambda In-Reply-To: References: <46902333.sKiuf4kdI3@squirrel> Message-ID: I opened a ticket and replied: https://ghc.haskell.org/trac/ghc/ticket/13996#comment:1 Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Conal Elliott Sent: 19 July 2017 01:01 To: David Feuer Cc: ghc-devs at haskell.org Subject: Re: Repeated computations under a lambda Here's the code in question, slightly rephrased: > exampleC t = \ x -> x + s where s = sin t I wrote it this way so that `sin t` would be computed once per `t` and reused for each value of `x`. The intermediate result `s` has type `Double`---not a function. Without `-fno-do-lambda-eta-expansion`, phase 2 of `ghc -O` causes the `s = sin t` binding to be moved under the `\ x -> ...`. I've been using this programming style for this purpose for longer than I can remember, and apparently I've been mistaken about its effectiveness at least part of that time. -- Conal On Tue, Jul 18, 2017 at 4:52 PM, David Feuer > wrote: On Tuesday, July 18, 2017 3:55:28 PM EDT Conal Elliott wrote: > Hi Sebastian, > > Thanks for the reply. It's that I don't want `exampleC` to be eta-expanded. > Apparently GHC does by default even when doing so moves computation under > lambda. I've thought otherwise for a very long time. GHC really likes to eta-expand, because that can be very good for allocation, unboxing, and I don't know what else. Do you really need to represent the intermediate result by a *function*? Would it work just to save the Double itself? I suspect you could likely convince GHC to leave it alone. David -------------- next part -------------- An HTML attachment was scrubbed... URL: From conal at conal.net Wed Jul 19 16:09:05 2017 From: conal at conal.net (Conal Elliott) Date: Wed, 19 Jul 2017 09:09:05 -0700 Subject: Repeated computations under a lambda In-Reply-To: <1500429106.9535.4.camel@joachim-breitner.de> References: <46902333.sKiuf4kdI3@squirrel> <1500429106.9535.4.camel@joachim-breitner.de> Message-ID: > GHC does this transformation not nilly-willy, .... If that > code would call some unknown function, or allocate memory, then GHC > would certainly preserve your intention. Wonderful. Thanks for the clarification. -- Conal On Tue, Jul 18, 2017 at 6:51 PM, Joachim Breitner wrote: > Hi, > > Am Dienstag, den 18.07.2017, 17:01 -0700 schrieb Conal Elliott: > > Here's the code in question, slightly rephrased: > > > > > exampleC t = \ x -> x + s where s = sin t > > > > I wrote it this way so that `sin t` would be computed once per `t` > > and reused for each value of `x`. The intermediate result `s` has > > type `Double`---not a function. Without `-fno-do-lambda-eta- > > expansion`, phase 2 of `ghc -O` causes the `s = sin t` binding to be > > moved under the `\ x -> ...`. I've been using this programming style > > for this purpose for longer than I can remember, and apparently I've > > been mistaken about its effectiveness at least part of that time. > > usually it is very effective. GHC does this transformation not nilly- > willy, but only when its heuristics indicate that it is ok, usually > because the operation (here sin) is known to be very cheap. If that > code would call some unknown function, or allocate memory, then GHC > would certainly preserve your intention. > > Greetings, > Joachim > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Fri Jul 21 07:50:32 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 21 Jul 2017 07:50:32 +0000 Subject: D3754: Refactor uo_thing In-Reply-To: References: Message-ID: Richard I'm on a train, so can't look at the detail. But the following thought occurs to me. uo_thing is a Maybe SDoc attached to a constraint. But a constraint also has a stack of [ErrCtxt], captured in the CtLoc. That's what produces the "In the declaration for ..." stuff. Idea: instead of uo_thing, could we just push an extra ErrCtxt onto the stack, in the CtLoc for this constraint? (Or not, in the Nothing case.) Simon From: noreply at phabricator.haskell.org [mailto:noreply at phabricator.haskell.org] Sent: 18 July 2017 19:39 To: Simon Peyton Jones Subject: [Differential] [Request, 533 lines] D3754: Refactor uo_thing goldfire created this revision. Herald added subscribers: thomie, rwbarton. Herald added a reviewer: hvr. View Revision REVISION SUMMARY The uo_thing field of TypeEqOrigin is used to track the "thing" (either term or type) that has the type (kind) stored in the TypeEqOrigin fields. Previously, this was sometimes a proper Core Type, which needed zonking and tidying. Now, it is only HsSyn: much simpler, and the error messages now use the user-written syntax. But this aspect of uo_thing didn't cause Trac #13819; it was the sibling field uo_arity that did. uo_arity stored the number of arguments of uo_thing, useful when reporting something like "should have written 2 fewer arguments". We wouldn't want to say that if the thing didn't have two arguments. However, in practice, GHC was getting this wrong, and this message didn't seem all that helpful. Furthermore, the calculation of the number of arguments is what caused Trac #13819 to fall over. This patch just removes uo_arity. In my opinion, the change to error messages is a nudge in the right direction. Test case: typecheck/should_fail/T13819 TEST PLAN ./validate REPOSITORY rGHC Glasgow Haskell Compiler BRANCH wip/rae REVISION DETAIL https://phabricator.haskell.org/D3754 AFFECTED FILES compiler/ghci/RtClosureInspect.hs compiler/typecheck/Inst.hs compiler/typecheck/TcArrows.hs compiler/typecheck/TcErrors.hs compiler/typecheck/TcExpr.hs compiler/typecheck/TcHsType.hs compiler/typecheck/TcMType.hs compiler/typecheck/TcPat.hs compiler/typecheck/TcRnTypes.hs compiler/typecheck/TcSigs.hs compiler/typecheck/TcSplice.hs compiler/typecheck/TcSplice.hs-boot compiler/typecheck/TcTyClsDecls.hs compiler/typecheck/TcType.hs compiler/typecheck/TcUnify.hs compiler/typecheck/TcUnify.hs-boot compiler/types/Type.hs testsuite/tests/indexed-types/should_fail/T12867.stderr testsuite/tests/polykinds/T12593.stderr testsuite/tests/polykinds/T6039.stderr testsuite/tests/polykinds/T7278.stderr testsuite/tests/polykinds/T8616.stderr testsuite/tests/polykinds/T9200b.stderr testsuite/tests/rename/should_fail/rnfail026.stderr testsuite/tests/th/T3177a.stderr testsuite/tests/typecheck/should_fail/T11356.stderr testsuite/tests/typecheck/should_fail/T11672.stderr testsuite/tests/typecheck/should_fail/T12785b.stderr testsuite/tests/typecheck/should_fail/T13819.hs testsuite/tests/typecheck/should_fail/T13819.stderr testsuite/tests/typecheck/should_fail/T2994.stderr testsuite/tests/typecheck/should_fail/T3540.stderr testsuite/tests/typecheck/should_fail/T4875.stderr testsuite/tests/typecheck/should_fail/T7609.stderr testsuite/tests/typecheck/should_fail/T7778.stderr testsuite/tests/typecheck/should_fail/all.T testsuite/tests/typecheck/should_fail/tcfail070.stderr testsuite/tests/typecheck/should_fail/tcfail078.stderr testsuite/tests/typecheck/should_fail/tcfail113.stderr testsuite/tests/typecheck/should_fail/tcfail123.stderr testsuite/tests/typecheck/should_fail/tcfail132.stderr EMAIL PREFERENCES https://phabricator.haskell.org/settings/panel/emailpreferences/ To: goldfire, simonpj, austin, bgamari, hvr Cc: rwbarton, thomie, Mikolaj, fryguybob, carter, mpickering, adamgundry -------------- next part -------------- An HTML attachment was scrubbed... URL: From siddu.druid at gmail.com Sat Jul 22 21:26:37 2017 From: siddu.druid at gmail.com (Siddharth Bhat) Date: Sat, 22 Jul 2017 21:26:37 +0000 Subject: [GHC] #14005: Explore moving from pretty to prettyprinter In-Reply-To: <061.84af9cab89a4103121305c13178576e4@haskell.org> References: <046.00a7ed7516b897a5e7cf99ebffe5bc6d@haskell.org> <061.84af9cab89a4103121305c13178576e4@haskell.org> Message-ID: Ben, Thank you for the fix :) However, the link appears to be broken? On Sat, 22 Jul 2017 at 23:15 GHC wrote: > #14005: Explore moving from pretty to prettyprinter > -------------------------------------+------------------------------------- > Reporter: bgamari | Owner: (none) > Type: task | Status: new > Priority: normal | Milestone: 8.4.1 > Component: Compiler | Version: 8.0.1 > Resolution: | Keywords: > Operating System: Unknown/Multiple | Architecture: > | Unknown/Multiple > Type of failure: None/Unknown | Test Case: > Blocked By: | Blocking: > Related Tickets: | Differential Rev(s): Phab:D3650 > Wiki Page: | > wiki:PrettyErrors | > -------------------------------------+------------------------------------- > > Comment (by bgamari): > > For the record, my > [[ > https://github.com/bgamari/ghc/commit/5256c89d3172d353d4ebc595b8c38c7ae5a796c9|branch > ]] > contains a rather hacky fix for this in issue (at least in the case of the > NCG). > > -- > Ticket URL: > GHC > The Glasgow Haskell Compiler > -- Sending this from my phone, please excuse any typos! -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Sun Jul 23 03:03:28 2017 From: ben at well-typed.com (Ben Gamari) Date: Sat, 22 Jul 2017 23:03:28 -0400 Subject: [ANNOUNCE] GHC 8.2.1 available Message-ID: <87bmobrh1b.fsf@ben-laptop.smart-cactus.org> =============================================== The Glasgow Haskell Compiler -- version 8.2.1 =============================================== The GHC developers are very happy to announce the long-awaited 8.2.1 release of Glasgow Haskell Compiler. Binary and source distributions can be found at https://downloads.haskell.org/~ghc/8.2.1/ This is the second release in the 8.0 series. As such, the focus of this release is performance, stability, and consolidation. Consequently numerous cleanups can be seen throughout the compiler including, * Significant improvements in compiler performance * More robust support for levity polymorphism * Reliable DWARF debugging information * Improved runtime system performance on NUMA systems * Retooling of the cost-center profiler, including support for live streaming of profile data via the GHC event log * Interface file determinism * More robust treatment of join points, enabling significantly better code generation in many cases * Numerous improvements in robustness on Windows * and the resolution of over 500 other tickets In addition, there are a number of new features, * A new, more type-safe type reflection mechanism * The long-awaited Backpack module system * Deriving strategies to disambiguate between GHC's various instance deriving mechanisms * Unboxed sum types, for efficient unpacked representation of sum data types * Compact regions, allowing better control over garbage collection in the presence of large heaps containing many long-lived objects. * Colorful messages and caret diagnostics for more legible errors A more thorough list of the changes in this release can be found in the release notes, https://haskell.org/ghc/docs/8.2.1/docs/html/users_guide/8.2.1-notes.html There are a few changes in release-engineering that should be noted, * Binary distributions for 32-bit CentOS 6.7 have been dropped. Moreover, there are no dedicated CentOS 7.0 distributions as CentOS 7 can use can use Debian 8 binaries. If you would like us to continue to produce 32-bit CentOS 6.7 distributions please let us know. * GHC HQ now builds FreeBSD and OpenBSD distributions for amd64; this comes after many years of these distributions being faithfully provided by Karel Gardas and Pali Gabor Janos, who we should heartily thank for their contributions. GHC HQ building these distributions ourselves will allow us to more quickly ship distributions to users by eliminating the need for a long lag time between source release availability and having all binary distributions available. * There is a technology-preview of an AArch64 Linux binary distribution, as well as an ARM Linux build. AArch64 support is quite preliminary but should be stable in 8.4 thanks to further linker fixes by Moritz Angerman. ARM should be stable. * GHC now tries to use the gold and lld linkers by default. These linkers are significantly faster than the BFD linker implementation that most Linux distributions use by default. If gold or lld are not available GHC will use the system's default linker. GHC can be forced to use the default linker by passing --disable-ld-override to configure. This release has been the result of over a year of hard work by over 150 code contributors. Thanks to everyone who has helped in writing patches, testing, reporting bugs, and offering feedback over the last year. This release cycle was admittedly quite drawn out, significantly longer than expected or desired. While we are confident that the result is worth the wait, we have been steadily working on infrastructure which should help shrink future release cycles and give us better testing between releases. More details on this coming soon. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at well-typed.com Sun Jul 23 13:41:31 2017 From: ben at well-typed.com (Ben Gamari) Date: Sun, 23 Jul 2017 09:41:31 -0400 Subject: [ANNOUNCE] GHC 8.2.1 available In-Reply-To: <87bmobrh1b.fsf@ben-laptop.smart-cactus.org> References: <87bmobrh1b.fsf@ben-laptop.smart-cactus.org> Message-ID: <8760ejqnhw.fsf@ben-laptop.smart-cactus.org> Minor editorial note (thanks to everyone who brought this to my attention): The URL listed in the announcement for the release notes isn't quite right. The release notes can be found at, > https://haskell.org/ghc/docs/8.2.1/html/users_guide/8.2.1-notes.html > Sorry for the confusion. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From hvriedel at gmail.com Mon Jul 24 10:24:21 2017 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Mon, 24 Jul 2017 12:24:21 +0200 Subject: Reinstallable lib:ghc (was: [core libraries] Upgradeable base (smallest step forward)) In-Reply-To: <878tyjbmca.fsf@gmail.com> (Herbert Valerio Riedel's message of "Sun, 05 Jun 2016 19:02:29 +0200") References: <1465130147.9731.7.camel@joachim-breitner.de> <878tyjbmca.fsf@gmail.com> Message-ID: <87o9sayvxm.fsf_-_@gmail.com> Hi everyone, As part of the recent GHC 8.2.1 release and the associated boot-library publishing to Hackage, I picked up again experimenting with a reinstallable lib:ghc package primarily for the benefit of uploading haddocks for lib:ghc (w/ `--hyperlinked-source`) to Hackage: http://hackage.haskell.org/package/ghc However, this also provides somewhat of a tech-preview of a reinstallable lib:ghc package, which would help mitigate a big issue we had in the past with lib:ghc and its dependencies being frozen to specific versions, and which in combination with cabal's nix-style pkg store that finally provide us with the ability to have multiple instances of the same library versions co-existing in the same package db, is no longer a requirement. So we could have lib:ghc more easily pick dependencies up (but still within reason!) like e.g. lib:text without forcing everyone to the single lib:text version bundled with GHC. And we'd also gain the ability to publish patch-level releases to lib:ghc only inbetween proper minor GHC releases (e.g. to support new versions of library dependencies). Consider this artificial example demo package which requires a different version of binary than the one bundled with GHC 8.2.1: --8<---------------cut here---------------start------------->8--- -- ghc-demo.cabal name: ghc-demo version: 0 build-type: Simple cabal-version: >=2.0 executable ghc-demo main-is: Main.hs build-depends: base ^>= 4.10, ghc ^>= 8.2.1, binary == 0.8.5.0 default-language: Haskell2010 --8<---------------cut here---------------end--------------->8--- Trying to build this will have the cabal solver complain that the installed instance of ghc requires a different (& installed) version of binary, i.e. binary-0.8.5.1. Moreover, the source version of lib:ghc on Hackage has the manual `buildable` cabal flag which defaults to false, and currently prevents lib:ghc to be reinstalled automatically (by enabling an unsatisfiable constraint): --8<---------------cut here---------------start------------->8--- Resolving dependencies... cabal: Could not resolve dependencies: trying: base-4.10.0.0/installed-4.1... (dependency of ghc-demo-0) next goal: ghc (dependency of ghc-demo-0) rejecting: ghc-8.2.1/installed-8.2... (conflict: binary==0.8.5.0, ghc => binary==0.8.5.1/installed-0.8...) trying: ghc-8.2.1 rejecting: ghc-8.2.1:-buildable (conflict: base==4.10.0.0/installed-4.1..., ghc -buildable => base<0) rejecting: ghc-8.2.1:+buildable (manual flag can only be changed explicitly) After searching the rest of the dependency tree exhaustively, these were the goals I've had most trouble fulfilling: ghc-demo, binary, base, ghc, ghc-8.2.1:buildable --8<---------------cut here---------------end--------------->8--- However, if we unlock this by toggling the flag (NB: this only works on linux/x86_64; it's explained later why), e.g. --8<---------------cut here---------------start------------->8--- -- cabal.project file packages: . package ghc flags: +buildable --8<---------------cut here---------------end--------------->8--- The cabal solver would come up with an install-plan: --8<---------------cut here---------------start------------->8--- Resolving dependencies... Build profile: -w ghc-8.2.1 -O1 In order, the following will be built (use -v for more details): - binary-0.8.5.0 {binary-0.8.5.0-7f686cf5c40c3c685540306709c4a2a30d740679f5d31ad196283d242a4d70ac} (lib) (requires download & build) - ghc-boot-8.2.1 {ghc-boot-8.2.1-7930c3d78690c5fa476415d38abbb7717b05cf65e80cc79c12e782c9886507cb} (lib) (requires build) - ghci-8.2.1 {ghci-8.2.1-6292924619a045fd18e9fde0cfa350632672ad7439cb84a5c56ff0e4781346b1} (lib) (requires build) - ghc-8.2.1 {ghc-8.2.1-bc10931b0f169622deb74d84cf10e315730dfd8f2edcf4cad9073d142cf5da0c} (lib) +buildable (requires build) - ghc-demo-0 {ghc-demo-0-inplace-ghc-demo} (exe:ghc-demo) (first run) Configuring binary-0.8.5.0-7f686cf5c40c3c685540306709c4a2a30d740679f5d31ad196283d242a4d70ac (lib) Building binary-0.8.5.0-7f686cf5c40c3c685540306709c4a2a30d740679f5d31ad196283d242a4d70ac (lib) Installing binary-0.8.5.0-7f686cf5c40c3c685540306709c4a2a30d740679f5d31ad196283d242a4d70ac (lib) Finished binary-0.8.5.0-7f686cf5c40c3c685540306709c4a2a30d740679f5d31ad196283d242a4d70ac (lib) Configuring ghc-boot-8.2.1-7930c3d78690c5fa476415d38abbb7717b05cf65e80cc79c12e782c9886507cb (lib) Building ghc-boot-8.2.1-7930c3d78690c5fa476415d38abbb7717b05cf65e80cc79c12e782c9886507cb (lib) Installing ghc-boot-8.2.1-7930c3d78690c5fa476415d38abbb7717b05cf65e80cc79c12e782c9886507cb (lib) Finished ghc-boot-8.2.1-7930c3d78690c5fa476415d38abbb7717b05cf65e80cc79c12e782c9886507cb (lib) Configuring ghci-8.2.1-6292924619a045fd18e9fde0cfa350632672ad7439cb84a5c56ff0e4781346b1 (lib) Building ghci-8.2.1-6292924619a045fd18e9fde0cfa350632672ad7439cb84a5c56ff0e4781346b1 (lib) Installing ghci-8.2.1-6292924619a045fd18e9fde0cfa350632672ad7439cb84a5c56ff0e4781346b1 (lib) Finished ghci-8.2.1-6292924619a045fd18e9fde0cfa350632672ad7439cb84a5c56ff0e4781346b1 (lib) Configuring ghc-8.2.1-bc10931b0f169622deb74d84cf10e315730dfd8f2edcf4cad9073d142cf5da0c (lib) Building ghc-8.2.1-bc10931b0f169622deb74d84cf10e315730dfd8f2edcf4cad9073d142cf5da0c (lib) Installing ghc-8.2.1-bc10931b0f169622deb74d84cf10e315730dfd8f2edcf4cad9073d142cf5da0c (lib) Finished ghc-8.2.1-bc10931b0f169622deb74d84cf10e315730dfd8f2edcf4cad9073d142cf5da0c (lib) Configuring executable 'ghc-demo' for ghc-demo-0.. Preprocessing executable 'ghc-demo' for ghc-demo-0.. Building executable 'ghc-demo' for ghc-demo-0.. [1 of 1] Compiling Main ( Main.hs, /tmp/lll/dist-newstyle/build/x86_64-linux/ghc-8.2.1/ghc-demo-0/c/ghc-demo/build/ghc-demo/ghc-demo-tmp/Main.o ) Linking /tmp/lll/dist-newstyle/build/x86_64-linux/ghc-8.2.1/ghc-demo-0/c/ghc-demo/build/ghc-demo/ghc-demo ... --8<---------------cut here---------------end--------------->8--- So, cabal was able to succesfully produce an executable which uses a reinstalled lib:ghc w/ a different lib:binary version! But now for the limitations: this currently works at best with a GHC 8.2.1 installation whose configuration matches the generated files I manually included in the modified lib:ghc package in http://hackage.haskell.org/package/ghc-8.2.1/src/autogen/ which as you can see from the generated files (see e.g. Config.hs) was a Linux/x86_64/libgmp/internal-libffi/... configuration. ...and this finally brings me to the purpose of why I wrote this email: In order to make lib:ghc properly reinstallable we'd need to either a) have a way to regenerate the files autogen/* via a custom Setup.hs (by the likes of genprimcode or similiar) or the lazy option, b) simply have those files installed in a place we can easily locate (again, from a custom Setup.hs) Does this make any sense; which option do you prefer? Also, I'd like to know if you can think of reasons why or situations when the reinstalled lib:ghc wouldn't work; or other reasons why this is a bad idea. Cheers, hvr On 2016-06-05 at 19:02:29 +0200, Herbert Valerio Riedel wrote: >> As an ultimate goal for a project like this, it would be nice if you could >> do something like upgrade your base package but continue to use the ghc >> package without incompatible types. > > That's one way to approach this. However, I've been experimenting with a > more flexible way: Thanks to cabal-1.24's new nix-based tech-preview > which gets rid of that `--force-reinstall` abomination for good, the > prospect of simply recompiling the `ghc` cabal package becomes more > attractive. > > This would get rid of the primary reason which currently constraints us > to using the package versions bundled in GHC (like e.g. for > `bytestring`) as soon as `ghc` enters an install-plan. > > I'm still investigating this, but early experiments were promising, but > I need to reorganise GHC's source-tree a little bit to know for sure if > this is feasable. But if this as I hope is possible, this could open up > a lot of new possibilities! From rae at cs.brynmawr.edu Mon Jul 24 12:23:33 2017 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Mon, 24 Jul 2017 08:23:33 -0400 Subject: D3754: Refactor uo_thing In-Reply-To: References: Message-ID: <2C7C2932-ADF9-4606-AC70-B256C84BFEA5@cs.brynmawr.edu> Hi Simon, I suppose this is possible, but it would change lots of error messages. (Currently, the uo_thing -- when reported -- is included inline with other parts of the message.) In my opinion, if we're going to reformat error messages, we could do better than this, anyway. I'm thinking of something like Type mismatch error: `uo_thing` has one type, but I expected a different type. type of `uo_thing`: `actual` expected type: `expected` where `expected` and `actual` are vertically aligned, as they are today. (This would require the ability to query the rendered length of an SDoc, which is not currently possible... but I don't think would be all that hard, as long as we were in a context that returned an SDoc.) What I like about this formatting is that it puts `uo_thing` right at the top of the error; this is the chunk of user-written syntax that causes the error. I've not tried this yet because I haven't the time to sift through the thousand error-message changes that this would cause. Putting uo_thing in the ErrCtxt would make something like this impossible, I think. Richard > On Jul 21, 2017, at 3:50 AM, Simon Peyton Jones wrote: > > Richard > > I’m on a train, so can’t look at the detail. But the following thought occurs to me. > > uo_thing is a Maybe SDoc attached to a constraint. But a constraint also has a stack of [ErrCtxt], captured in the CtLoc. That’s what produces the “In the declaration for …” stuff. > > Idea: instead of uo_thing, could we just push an extra ErrCtxt onto the stack, in the CtLoc for this constraint? (Or not, in the Nothing case.) > > Simon >   <> > From: noreply at phabricator.haskell.org [mailto:noreply at phabricator.haskell.org] > Sent: 18 July 2017 19:39 > To: Simon Peyton Jones > Subject: [Differential] [Request, 533 lines] D3754: Refactor uo_thing > > goldfire created this revision. > Herald added subscribers: thomie, rwbarton. > Herald added a reviewer: hvr. > > View Revision > > > REVISION SUMMARY > > The uo_thing field of TypeEqOrigin is used to track the > "thing" (either term or type) that has the type (kind) stored > in the TypeEqOrigin fields. Previously, this was sometimes a > proper Core Type, which needed zonking and tidying. Now, it > is only HsSyn: much simpler, and the error messages now use > the user-written syntax. > > But this aspect of uo_thing didn't cause Trac #13819 ; it was the > sibling field uo_arity that did. uo_arity stored the number > of arguments of uo_thing, useful when reporting something > like "should have written 2 fewer arguments". We wouldn't want > to say that if the thing didn't have two arguments. However, > in practice, GHC was getting this wrong, and this message > didn't seem all that helpful. Furthermore, the calculation > of the number of arguments is what caused Trac #13819 to fall over. > This patch just removes uo_arity. In my opinion, the change > to error messages is a nudge in the right direction. > > Test case: typecheck/should_fail/T13819 > > > TEST PLAN > ./validate > > > REPOSITORY > rGHC Glasgow Haskell Compiler > > BRANCH > wip/rae > > REVISION DETAIL > https://phabricator.haskell.org/D3754 > > AFFECTED FILES > compiler/ghci/RtClosureInspect.hs > compiler/typecheck/Inst.hs > compiler/typecheck/TcArrows.hs > compiler/typecheck/TcErrors.hs > compiler/typecheck/TcExpr.hs > compiler/typecheck/TcHsType.hs > compiler/typecheck/TcMType.hs > compiler/typecheck/TcPat.hs > compiler/typecheck/TcRnTypes.hs > compiler/typecheck/TcSigs.hs > compiler/typecheck/TcSplice.hs > compiler/typecheck/TcSplice.hs-boot > compiler/typecheck/TcTyClsDecls.hs > compiler/typecheck/TcType.hs > compiler/typecheck/TcUnify.hs > compiler/typecheck/TcUnify.hs-boot > compiler/types/Type.hs > testsuite/tests/indexed-types/should_fail/T12867.stderr > testsuite/tests/polykinds/T12593.stderr > testsuite/tests/polykinds/T6039.stderr > testsuite/tests/polykinds/T7278.stderr > testsuite/tests/polykinds/T8616.stderr > testsuite/tests/polykinds/T9200b.stderr > testsuite/tests/rename/should_fail/rnfail026.stderr > testsuite/tests/th/T3177a.stderr > testsuite/tests/typecheck/should_fail/T11356.stderr > testsuite/tests/typecheck/should_fail/T11672.stderr > testsuite/tests/typecheck/should_fail/T12785b.stderr > testsuite/tests/typecheck/should_fail/T13819.hs > testsuite/tests/typecheck/should_fail/T13819.stderr > testsuite/tests/typecheck/should_fail/T2994.stderr > testsuite/tests/typecheck/should_fail/T3540.stderr > testsuite/tests/typecheck/should_fail/T4875.stderr > testsuite/tests/typecheck/should_fail/T7609.stderr > testsuite/tests/typecheck/should_fail/T7778.stderr > testsuite/tests/typecheck/should_fail/all.T > testsuite/tests/typecheck/should_fail/tcfail070.stderr > testsuite/tests/typecheck/should_fail/tcfail078.stderr > testsuite/tests/typecheck/should_fail/tcfail113.stderr > testsuite/tests/typecheck/should_fail/tcfail123.stderr > testsuite/tests/typecheck/should_fail/tcfail132.stderr > > EMAIL PREFERENCES > https://phabricator.haskell.org/settings/panel/emailpreferences/ > > To: goldfire, simonpj, austin, bgamari, hvr > Cc: rwbarton, thomie, Mikolaj, fryguybob, carter, mpickering, adamgundry -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Mon Jul 24 19:04:21 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 24 Jul 2017 15:04:21 -0400 Subject: Reinstallable lib:ghc (was: [core libraries] Upgradeable base (smallest step forward)) In-Reply-To: <87o9sayvxm.fsf_-_@gmail.com> References: <1465130147.9731.7.camel@joachim-breitner.de> <878tyjbmca.fsf@gmail.com> <87o9sayvxm.fsf_-_@gmail.com> Message-ID: <1500923061.4259.3.camel@joachim-breitner.de> Hi, Am Montag, den 24.07.2017, 12:24 +0200 schrieb Herbert Valerio Riedel: > Also, I'd like to know if you can think of reasons why or situations > when the reinstalled lib:ghc wouldn't work; or other reasons why this > is a bad idea. I’d am mostly worried about ABI compatibility. Will the .hi files written by the compiler be readable by some tool that was built with an upgraded ghc? Which dependencies can affect the binary format (if any)? Or will the rebuilt ghc get its own, randomly generated “GHC version” (similar to a development build where the build date is part of the GHC version) and hence never try to interact with build artifacts created from the host ghc? Also, if we can `cabal install ghc-the-library`, can we also `cabal install ghc-the-program`, possibly at a different version? (It wouldn’t be normally usable without bootstrapping a RTS and base library, but it would be a step.) Greetings, Joachim -- Joachim “nomeata” Breitner   mail at joachim-breitner.de • https://www.joachim-breitner.de/   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F   Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From matthewtpickering at gmail.com Tue Jul 25 13:44:11 2017 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Tue, 25 Jul 2017 14:44:11 +0100 Subject: Frontend Plugins Proposal Message-ID: 4 years ago Edsko proposed a patch to add support for frontend plugins to GHC. You can read his proposal here - https://ghc.haskell.org/trac/ghc/wiki/FrontendPluginsProposal#no1 Something like core to core plugins but for typechecked code would be useful for tool writers. Does anyone know why the patch was never merged? Confusingly Edward Yang implemented another feature called frontend plugins which does something quite different (allowing users to write custom major modes rather than hook into the frontend). These features are quite different to each other. Thanks, Matt From ben at smart-cactus.org Tue Jul 25 16:44:36 2017 From: ben at smart-cactus.org (Ben Gamari) Date: Tue, 25 Jul 2017 12:44:36 -0400 Subject: Frontend Plugins Proposal In-Reply-To: References: Message-ID: <87pocopitn.fsf@ben-laptop.smart-cactus.org> Matthew Pickering writes: > 4 years ago Edsko proposed a patch to add support for frontend plugins > to GHC. You can read his proposal here - > https://ghc.haskell.org/trac/ghc/wiki/FrontendPluginsProposal#no1 > > Something like core to core plugins but for typechecked code would be > useful for tool writers. Does anyone know why the patch was never > merged? > This was before I started following closely, however, knowing how these things tend to go, I doubt that there was any strong objection to merging. It probably just got dropped. If we were to pick up this proposal again today it would certainly help if it provided some concrete motivation for the new plugin type. > Confusingly Edward Yang implemented another feature called frontend > plugins which does something quite different (allowing users to write > custom major modes rather than hook into the frontend). These features > are quite different to each other. > To be fair, Edsko's proposal refers to the proposed plugin type as a "source plugin" not a "frontend plugin", despite the Wiki page name. I think "source plugin" is a better name anyways. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From wolfgang-it at jeltsch.info Tue Jul 25 22:01:45 2017 From: wolfgang-it at jeltsch.info (Wolfgang Jeltsch) Date: Wed, 26 Jul 2017 01:01:45 +0300 Subject: [ANNOUNCE] GHC 8.2.1 available In-Reply-To: <87bmobrh1b.fsf@ben-laptop.smart-cactus.org> References: <87bmobrh1b.fsf@ben-laptop.smart-cactus.org> Message-ID: <1501020105.14379.125.camel@jeltsch.info> Am Samstag, den 22.07.2017, 23:03 -0400 schrieb Ben Gamari: > In addition, there are a number of new features, > >  * A new, more type-safe type reflection mechanism > >  * The long-awaited Backpack module system > >  * Deriving strategies to disambiguate between GHC's various instance >    deriving mechanisms > >  * Unboxed sum types, for efficient unpacked representation of sum >    data types > >  * Compact regions, allowing better control over garbage collection >    in the presence of large heaps containing many long-lived objects. > >  * Colorful messages and caret diagnostics for more legible errors > > A more thorough list of the changes in this release can be found in > the release notes, > >   https://haskell.org/ghc/docs/8.2.1/docs/html/users_guide/8.2.1-notes.html It seems that the release notes mention the new type reflection mechanism und colorful messages only in the “Highlights” section, not in the “Full details” section, and that they do not mention the Backpack module system and unboxed sums at all. All the best, Wolfgang From ben at smart-cactus.org Wed Jul 26 14:15:00 2017 From: ben at smart-cactus.org (Ben Gamari) Date: Wed, 26 Jul 2017 10:15:00 -0400 Subject: [ANNOUNCE] GHC 8.2.1 available In-Reply-To: <1501020105.14379.125.camel@jeltsch.info> References: <87bmobrh1b.fsf@ben-laptop.smart-cactus.org> <1501020105.14379.125.camel@jeltsch.info> Message-ID: <87h8xzp9nf.fsf@ben-laptop.smart-cactus.org> Wolfgang Jeltsch writes: > Am Samstag, den 22.07.2017, 23:03 -0400 schrieb Ben Gamari: >> In addition, there are a number of new features, >> >>  * A new, more type-safe type reflection mechanism >> >>  * The long-awaited Backpack module system >> >>  * Deriving strategies to disambiguate between GHC's various instance >>    deriving mechanisms >> >>  * Unboxed sum types, for efficient unpacked representation of sum >>    data types >> >>  * Compact regions, allowing better control over garbage collection >>    in the presence of large heaps containing many long-lived objects. >> >>  * Colorful messages and caret diagnostics for more legible errors >> >> A more thorough list of the changes in this release can be found in >> the release notes, >> >>   https://haskell.org/ghc/docs/8.2.1/docs/html/users_guide/8.2.1-notes.html > > It seems that the release notes mention the new type reflection > mechanism und colorful messages only in the “Highlights” section, not in > the “Full details” section, and that they do not mention the Backpack > module system and unboxed sums at all. > Yes, indeed these were oversights. They are fixed in the ghc-8.2 branch and I will try to push newly generated documentation shortly. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ezyang at mit.edu Thu Jul 27 00:35:06 2017 From: ezyang at mit.edu (Edward Z. Yang) Date: Wed, 26 Jul 2017 20:35:06 -0400 Subject: Reinstallable lib:ghc (was: [core libraries] Upgradeable base (smallest step forward)) In-Reply-To: <1500923061.4259.3.camel@joachim-breitner.de> References: <1465130147.9731.7.camel@joachim-breitner.de> <878tyjbmca.fsf@gmail.com> <87o9sayvxm.fsf_-_@gmail.com> <1500923061.4259.3.camel@joachim-breitner.de> Message-ID: <1501107570-sup-7979@sabre> Reinstalled GHC should be completely ABI compatible. This should actually not be difficult to achieve, since we already rely on this in the GHC build system: we assume that ghc-stage1 generated hi files can be compatibly read and used by ghc-stage2. Excerpts from Joachim Breitner's message of 2017-07-24 15:04:21 -0400: > Hi, > > Am Montag, den 24.07.2017, 12:24 +0200 schrieb Herbert Valerio Riedel: > > Also, I'd like to know if you can think of reasons why or situations > > when the reinstalled lib:ghc wouldn't work; or other reasons why this > > is a bad idea. > > I’d am mostly worried about ABI compatibility. Will the .hi files > written by the compiler be readable by some tool that was built with an > upgraded ghc? Which dependencies can affect the binary format (if any)? > > Or will the rebuilt ghc get its own, randomly generated “GHC version” > (similar to a development build where the build date is part of the GHC > version) and hence never try to interact with build artifacts created > from the host ghc? > > > Also, if we can `cabal install ghc-the-library`, can we also `cabal > install ghc-the-program`, possibly at a different version? (It wouldn’t > be normally usable without bootstrapping a RTS and base library, but it > would be a step.) > > Greetings, > Joachim > From qdunkan at gmail.com Thu Jul 27 01:45:44 2017 From: qdunkan at gmail.com (Evan Laforge) Date: Wed, 26 Jul 2017 18:45:44 -0700 Subject: [ANNOUNCE] GHC 8.2.1 available In-Reply-To: <87h8xzp9nf.fsf@ben-laptop.smart-cactus.org> References: <87bmobrh1b.fsf@ben-laptop.smart-cactus.org> <1501020105.14379.125.camel@jeltsch.info> <87h8xzp9nf.fsf@ben-laptop.smart-cactus.org> Message-ID: This seems like a silly question, but how can we install cabal-install now? The latest hackage version 1.24.0.2 has Cabal (>=1.24.2 && <1.25), but it looks like ghc Cabal is now at 2.*. I ran into this because if I get: % cabal install --only-dependencies Resolving dependencies... cabal: internal error when reading package index: failed to parse .cabal fileThe package index or index cache is probably corrupt. Running cabal update might fix it. It seems to be triggered by having 'ekg' in the deps list, since if I take it out then I get some other errors about packages not liking the new base, which is true. 'ekg' also doesn't like the new base, but "internal error" is not the clearest way to express that :) It's frustrating that cabal-install still doesn't report the parse error, even though the parse function returns one. It just ignores the ParseFailed case. I was going to try fixing it and send a pull request when I ran into the Cabal 2.* problem. On Wed, Jul 26, 2017 at 7:15 AM, Ben Gamari wrote: > Wolfgang Jeltsch writes: > >> Am Samstag, den 22.07.2017, 23:03 -0400 schrieb Ben Gamari: >>> In addition, there are a number of new features, >>> >>> * A new, more type-safe type reflection mechanism >>> >>> * The long-awaited Backpack module system >>> >>> * Deriving strategies to disambiguate between GHC's various instance >>> deriving mechanisms >>> >>> * Unboxed sum types, for efficient unpacked representation of sum >>> data types >>> >>> * Compact regions, allowing better control over garbage collection >>> in the presence of large heaps containing many long-lived objects. >>> >>> * Colorful messages and caret diagnostics for more legible errors >>> >>> A more thorough list of the changes in this release can be found in >>> the release notes, >>> >>> https://haskell.org/ghc/docs/8.2.1/docs/html/users_guide/8.2.1-notes.html >> >> It seems that the release notes mention the new type reflection >> mechanism und colorful messages only in the “Highlights” section, not in >> the “Full details” section, and that they do not mention the Backpack >> module system and unboxed sums at all. >> > Yes, indeed these were oversights. They are fixed in the ghc-8.2 branch > and I will try to push newly generated documentation shortly. > > Cheers, > > - Ben > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > From wolfgang-it at jeltsch.info Thu Jul 27 02:01:22 2017 From: wolfgang-it at jeltsch.info (Wolfgang Jeltsch) Date: Thu, 27 Jul 2017 05:01:22 +0300 Subject: [ANNOUNCE] GHC 8.2.1 available In-Reply-To: References: <87bmobrh1b.fsf@ben-laptop.smart-cactus.org> <1501020105.14379.125.camel@jeltsch.info> <87h8xzp9nf.fsf@ben-laptop.smart-cactus.org> Message-ID: <1501120882.2815.104.camel@jeltsch.info> Hi! I ran into the same problem. Apparently, we need cabal-install 2.0, which has not been released yet. A preliminary solution is to use the development version from the 2.0 branch. Binary packages can be found at      http://ppa.launchpad.net/hvr/ghc/ubuntu/pool/main/c/cabal-install-2.0/ , for example. It is possible to extract the cabal-install executable from these packages, so that it can be installed without using some Linux distribution package manager. All the best, Wolfgang Am Mittwoch, den 26.07.2017, 18:45 -0700 schrieb Evan Laforge: > This seems like a silly question, but how can we install cabal-install > now?  The latest hackage version 1.24.0.2 has Cabal (>=1.24.2 && > <1.25), but it looks like ghc Cabal is now at 2.*. > > I ran into this because if I get: > > % cabal install --only-dependencies > Resolving dependencies... > cabal: internal error when reading package index: failed to parse > .cabal > fileThe package index or index cache is probably corrupt. Running > cabal update > might fix it. > > It seems to be triggered by having 'ekg' in the deps list, since if I > take it out then I get some other errors about packages not liking the > new base, which is true.  'ekg' also doesn't like the new base, but > "internal error" is not the clearest way to express that :) > > It's frustrating that cabal-install still doesn't report the parse > error, even though the parse function returns one.  It just ignores > the ParseFailed case.  I was going to try fixing it and send a pull > request when I ran into the Cabal 2.* problem. > > On Wed, Jul 26, 2017 at 7:15 AM, Ben Gamari > wrote: > > > > Wolfgang Jeltsch writes: > > > > > > > > Am Samstag, den 22.07.2017, 23:03 -0400 schrieb Ben Gamari: > > > > > > > > In addition, there are a number of new features, > > > > > > > >  * A new, more type-safe type reflection mechanism > > > > > > > >  * The long-awaited Backpack module system > > > > > > > >  * Deriving strategies to disambiguate between GHC's various > > > > instance > > > >    deriving mechanisms > > > > > > > >  * Unboxed sum types, for efficient unpacked representation of > > > > sum > > > >    data types > > > > > > > >  * Compact regions, allowing better control over garbage > > > > collection > > > >    in the presence of large heaps containing many long-lived > > > > objects. > > > > > > > >  * Colorful messages and caret diagnostics for more legible > > > > errors > > > > > > > > A more thorough list of the changes in this release can be found > > > > in > > > > the release notes, > > > > > > > >   https://haskell.org/ghc/docs/8.2.1/docs/html/users_guide/8.2.1 > > > > -notes.html > > > It seems that the release notes mention the new type reflection > > > mechanism und colorful messages only in the “Highlights” section, > > > not in > > > the “Full details” section, and that they do not mention the > > > Backpack > > > module system and unboxed sums at all. > > > > > Yes, indeed these were oversights. They are fixed in the ghc-8.2 > > branch > > and I will try to push newly generated documentation shortly. > > > > Cheers, > > > > - Ben > > > > _______________________________________________ > > Glasgow-haskell-users mailing list > > Glasgow-haskell-users at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-use > > rs > > From simonpj at microsoft.com Thu Jul 27 12:01:24 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 27 Jul 2017 12:01:24 +0000 Subject: [commit: ghc] master: Improve error messages around kind mismatches. (8e15e3d) In-Reply-To: <20170727114949.4E8C83A585@ghc.haskell.org> References: <20170727114949.4E8C83A585@ghc.haskell.org> Message-ID: | typecheck/should_fail/T7368) Solution: track the provenance of | Derived constraints and refuse to float out a constraint that has | an insoluble Derived. For the record, that's not the solution that the patch implements. Instead we just don’t float heterogeneous equalities. I think Richard just forgot to update the commit message. Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On Behalf | Of git at git.haskell.org | Sent: 27 July 2017 12:50 | To: ghc-commits at haskell.org | Subject: [commit: ghc] master: Improve error messages around kind | mismatches. (8e15e3d) | | Repository : ssh://git at git.haskell.org/ghc | | On branch : master | Link : | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.ha | skell.org%2Ftrac%2Fghc%2Fchangeset%2F8e15e3d370e9c253ae0dbb330e25b72cb | 00cdb76%2Fghc&data=02%7C01%7Csimonpj%40microsoft.com%7C9993301a429e467 | e29b008d4d4e6350f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6363675 | 32584262688&sdata=bY%2Bruj0hhXfC23hfMA1ivuAs2Av2%2BY4%2BJK2yyCoPzbA%3D | &reserved=0 | | >--------------------------------------------------------------- | | commit 8e15e3d370e9c253ae0dbb330e25b72cb00cdb76 | Author: Richard Eisenberg | Date: Thu Jun 1 17:27:14 2017 -0400 | | Improve error messages around kind mismatches. | | Previously, when canonicalizing (or unifying, in uType) a | heterogeneous equality, we emitted a kind equality and used the | resulting coercion to cast one side of the heterogeneous equality. | | While sound, this led to terrible error messages. (See the bugs | listed below.) The problem is that using the coercion built from | the emitted kind equality is a bit like a wanted rewriting a | wanted. | The solution is to keep heterogeneous equalities as irreducible. | | See Note [Equalities with incompatible kinds] in TcCanonical. | | This commit also removes a highly suspicious switch to | FM_SubstOnly | when flattening in the kinds of a type variable. I have no idea | why this was there, other than as a holdover from pre-TypeInType. | I've not left a Note because there is simply no reason I can | conceive | of that the FM_SubstOnly should be there. | | One challenge with this patch is that the emitted derived | equalities | might get emitted several times: when a heterogeneous equality is | in an implication and then gets floated out from the implication, | the Derived is present both in and out of the implication. This | causes a duplicate error message. (Test case: | typecheck/should_fail/T7368) Solution: track the provenance of | Derived constraints and refuse to float out a constraint that has | an insoluble Derived. | | Lastly, this labels one test (dependent/should_fail/RAE_T32a) | as expect_broken, because the problem is really #12919. The | different handling of constraints in this patch exposes the error. | | This fixes bugs #11198, #12373, #13530, and #13610. | | test cases: | typecheck/should_fail/{T8262,T8603,tcail122,T12373,T13530,T13610} | | | >--------------------------------------------------------------- | | 8e15e3d370e9c253ae0dbb330e25b72cb00cdb76 | compiler/typecheck/TcCanonical.hs | 296 | ++++++++++++--------- | compiler/typecheck/TcErrors.hs | 75 ++++-- | compiler/typecheck/TcEvidence.hs | 8 +- | compiler/typecheck/TcFlatten.hs | 31 ++- | compiler/typecheck/TcRnTypes.hs | 30 ++- | compiler/typecheck/TcSimplify.hs | 34 ++- | compiler/typecheck/TcType.hs | 10 +- | compiler/typecheck/TcUnify.hs | 28 +- | compiler/types/Type.hs | 4 +- | testsuite/tests/dependent/should_fail/T11471.hs | 2 +- | .../tests/dependent/should_fail/T11471.stderr | 11 +- | testsuite/tests/dependent/should_fail/all.T | 2 +- | testsuite/tests/gadt/gadt7.stderr | 6 +- | .../tests/ghci.debugger/scripts/break012.stdout | 14 +- | .../indexed-types/should_fail/ExtraTcsUntch.stderr | 6 +- | .../tests/indexed-types/should_fail/T5934.stderr | 13 - | testsuite/tests/polykinds/T12593.stderr | 56 ++++ | testsuite/tests/polykinds/T13555.stderr | 21 +- | testsuite/tests/polykinds/T7438.stderr | 6 +- | testsuite/tests/polykinds/T8566.stderr | 2 +- | testsuite/tests/polykinds/T9017.stderr | 10 +- | testsuite/tests/typecheck/should_fail/T12373.hs | 10 + | .../tests/typecheck/should_fail/T12373.stderr | 8 + | testsuite/tests/typecheck/should_fail/T13530.hs | 11 + | .../tests/typecheck/should_fail/T13530.stderr | 7 + | testsuite/tests/typecheck/should_fail/T13610.hs | 11 + | .../tests/typecheck/should_fail/T13610.stderr | 14 + | testsuite/tests/typecheck/should_fail/T5691.stderr | 10 +- | testsuite/tests/typecheck/should_fail/T7368.stderr | 6 +- | .../tests/typecheck/should_fail/T7368a.stderr | 2 +- | testsuite/tests/typecheck/should_fail/T7453.stderr | 48 +--- | testsuite/tests/typecheck/should_fail/T7696.stderr | 4 +- | testsuite/tests/typecheck/should_fail/T8262.stderr | 6 +- | testsuite/tests/typecheck/should_fail/T8603.hs | 4 + | testsuite/tests/typecheck/should_fail/T8603.stderr | 13 +- | testsuite/tests/typecheck/should_fail/all.T | 3 + | .../tests/typecheck/should_fail/tcfail090.stderr | 4 +- | .../tests/typecheck/should_fail/tcfail122.stderr | 8 +- | .../tests/typecheck/should_fail/tcfail123.stderr | 13 +- | .../tests/typecheck/should_fail/tcfail200.stderr | 6 +- | 40 files changed, 537 insertions(+), 316 deletions(-) | | Diff suppressed because of size. To see it, use: | | git diff-tree --root --patch-with-stat --no-color --find-copies- | harder --ignore-space-at-eol --cc | 8e15e3d370e9c253ae0dbb330e25b72cb00cdb76 | _______________________________________________ | ghc-commits mailing list | ghc-commits at haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h | askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | commits&data=02%7C01%7Csimonpj%40microsoft.com%7C9993301a429e467e29b00 | 8d4d4e6350f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6363675325842 | 62688&sdata=JkrPJNfzdjx2Rz%2FfcMq2HlIP%2BlsFIE%2FT68a%2FSUae%2Fzo%3D&r | eserved=0 From rae at cs.brynmawr.edu Thu Jul 27 12:03:10 2017 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Thu, 27 Jul 2017 08:03:10 -0400 Subject: [commit: ghc] master: Improve error messages around kind mismatches. (8e15e3d) In-Reply-To: References: <20170727114949.4E8C83A585@ghc.haskell.org> Message-ID: > On Jul 27, 2017, at 8:01 AM, Simon Peyton Jones via ghc-devs wrote: > > I think Richard just forgot to update the commit message. Indeed. Bah. I don't suppose there's a way of fixing that now. Sorry! Richard From ben at well-typed.com Thu Jul 27 16:57:22 2017 From: ben at well-typed.com (Ben Gamari) Date: Thu, 27 Jul 2017 12:57:22 -0400 Subject: Harbormaster update Message-ID: <87vamdom19.fsf@ben-laptop.smart-cactus.org> Hello everyone, Note that the Harbormaster builders now bootstrap with GHC 8.2.1 and LLVM 3.9. I'll be on the lookout for any failures but ping me if you see Harbormaster fail to build your otherwise perfectly good patch. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From qdunkan at gmail.com Thu Jul 27 18:19:10 2017 From: qdunkan at gmail.com (Evan Laforge) Date: Thu, 27 Jul 2017 11:19:10 -0700 Subject: [ANNOUNCE] GHC 8.2.1 available In-Reply-To: <1501120882.2815.104.camel@jeltsch.info> References: <87bmobrh1b.fsf@ben-laptop.smart-cactus.org> <1501020105.14379.125.camel@jeltsch.info> <87h8xzp9nf.fsf@ben-laptop.smart-cactus.org> <1501120882.2815.104.camel@jeltsch.info> Message-ID: Thanks for the reply. I got cabal-install from https://github.com/haskell/cabal/ and assumed it was the latest version... but now that I look carefully I see it has a 2.0 branch. I compiled it and I don't get that confusing "parse error" any more. It looks like a nicer error message in general too (except still missing some spaces, specifically "After searching the rest of the dependency tree exhaustively, these were the goals I've had most trouble fulfilling: karya, ekgTrying configure anyway."), so that's probably thanks to the solver improvements in 2.0. Since it's apparently just a bug in older cabal-installs I guess I won't bother trying to find it. On Wed, Jul 26, 2017 at 7:01 PM, Wolfgang Jeltsch wrote: > Hi! > > I ran into the same problem. > > Apparently, we need cabal-install 2.0, which has not been released yet. > A preliminary solution is to use the development version from the 2.0 > branch. Binary packages can be found at > > http://ppa.launchpad.net/hvr/ghc/ubuntu/pool/main/c/cabal-install-2.0/ , > > for example. It is possible to extract the cabal-install executable from > these packages, so that it can be installed without using some Linux > distribution package manager. > > All the best, > Wolfgang > > Am Mittwoch, den 26.07.2017, 18:45 -0700 schrieb Evan Laforge: >> This seems like a silly question, but how can we install cabal-install >> now? The latest hackage version 1.24.0.2 has Cabal (>=1.24.2 && >> <1.25), but it looks like ghc Cabal is now at 2.*. >> >> I ran into this because if I get: >> >> % cabal install --only-dependencies >> Resolving dependencies... >> cabal: internal error when reading package index: failed to parse >> .cabal >> fileThe package index or index cache is probably corrupt. Running >> cabal update >> might fix it. >> >> It seems to be triggered by having 'ekg' in the deps list, since if I >> take it out then I get some other errors about packages not liking the >> new base, which is true. 'ekg' also doesn't like the new base, but >> "internal error" is not the clearest way to express that :) >> >> It's frustrating that cabal-install still doesn't report the parse >> error, even though the parse function returns one. It just ignores >> the ParseFailed case. I was going to try fixing it and send a pull >> request when I ran into the Cabal 2.* problem. >> >> On Wed, Jul 26, 2017 at 7:15 AM, Ben Gamari >> wrote: >> > >> > Wolfgang Jeltsch writes: >> > >> > > >> > > Am Samstag, den 22.07.2017, 23:03 -0400 schrieb Ben Gamari: >> > > > >> > > > In addition, there are a number of new features, >> > > > >> > > > * A new, more type-safe type reflection mechanism >> > > > >> > > > * The long-awaited Backpack module system >> > > > >> > > > * Deriving strategies to disambiguate between GHC's various >> > > > instance >> > > > deriving mechanisms >> > > > >> > > > * Unboxed sum types, for efficient unpacked representation of >> > > > sum >> > > > data types >> > > > >> > > > * Compact regions, allowing better control over garbage >> > > > collection >> > > > in the presence of large heaps containing many long-lived >> > > > objects. >> > > > >> > > > * Colorful messages and caret diagnostics for more legible >> > > > errors >> > > > >> > > > A more thorough list of the changes in this release can be found >> > > > in >> > > > the release notes, >> > > > >> > > > https://haskell.org/ghc/docs/8.2.1/docs/html/users_guide/8.2.1 >> > > > -notes.html >> > > It seems that the release notes mention the new type reflection >> > > mechanism und colorful messages only in the “Highlights” section, >> > > not in >> > > the “Full details” section, and that they do not mention the >> > > Backpack >> > > module system and unboxed sums at all. >> > > >> > Yes, indeed these were oversights. They are fixed in the ghc-8.2 >> > branch >> > and I will try to push newly generated documentation shortly. >> > >> > Cheers, >> > >> > - Ben >> > >> > _______________________________________________ >> > Glasgow-haskell-users mailing list >> > Glasgow-haskell-users at haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-use >> > rs >> > From simonpj at microsoft.com Fri Jul 28 08:18:10 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 28 Jul 2017 08:18:10 +0000 Subject: Operating on HsSyn Message-ID: Devs, Shayan is working away on "Trees that grow"... do keep it on your radar: To: ghc-devs Sent: 25 May 2017 23:49 Do take a look at this: * We propose to re-engineer HsSyn itself. This will touch a lot of code. * But it's very neat, and will bring big long-term advantages * And we can do it a bit at a time The wiki page https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow has the details. It's entirely an internal change, not a change to GHC's specification, so it's independent of the GHC proposals process. But I'd value the opinion of other GHC devs Meanwhile I have a question. When pretty-printing HsSyn we often have a situation like this: data Pass = Parsed | Renamed | Typechecked data HsExpr (p :: Pass) = HsVar (IdP p) | .... type famliy IdP p where IdP Parsed = RdrName IdP Renamed = Name IdP Typechecked = Id instance (Outputable (IdP p)) => Outputable (HsExpr p) where ppr (HsVar v) = ppr v The (ppr v) requires (Outputable (IdP p)), hence the context. Moreover, and more seriously, there are things we just can't pretty-print right now. For example, HsExpr has this data constructor: data HsExpr p = ... | OpApp (LHsExpr p) (LHsExpr p) (PostRn p Fixity) (LHsExpr p) To pretty-print the third argument, we'd need to add instance (Outputable (IdP p), Outputable (PostRn p Fixity)) -- New => Outputable (HsExpr p) where ppr (HsVar v) = ppr v and that gets onerous. So today we never print these annotations, to avoid bloating the instance contexts, which can be painful. It bit me yesterday. We have bitten that bullet for the Data class: look at HsExtension.DataId, which abbreviates the long list of dictionaries: type DataId p = ( Data p , ForallX Data p , Data (NameOrRdrName (IdP p)) , Data (IdP p) , Data (PostRn p (IdP p)) , Data (PostRn p (Located Name)) , Data (PostRn p Bool) , Data (PostRn p Fixity) ,..and nine more... ) Let me note in passing that [wiki:QuantifiedContexts] would make this somewhat shorter type DataId p = ( Data p , ForallX Data p , Data (NameOrRdrName (IdP p)) , Data (IdP p) , forall t. Data t => Data (PostRn p t)) But we still need one item in this list for each type function, and I am worried about how this scales to the [wiki:ImplementingTreesThatGrow] story, when we have a type function for each data constructor -- and there are a lot of data constructors. So I have four questions 1. I think we should probably use a superclass instead of a type synonym class (Data p, ForallX Data p, ....) => DataId p where {} Why? Only one argument to pass, and to pass on to successive calls. I see no downside. 1. Shall we treat Outputable like Data? (I.e. make an abbreviation for a long list of Outputable instances and use it everywhere) 2. I thought of another way to do it (pass a token); see below 1. Are there any other ways? Token passing idea. Perhaps instead of passing lots of functions, we pass a singleton token that encodes the pass, like this: instance (PassC p) => Outputable (HsExpr p) where ppr (HsVar v) = case getPass :: IsPass p of IsParsed -> ppr v IsRenamed -> ppr v IsTypechecked -> ppr v The three ppr's are at different types, of course; that's the point. The infrastructure is something like class PassC p where getPass :: IsPass p data IsPass p where IsParsed :: IsPass Parsed IsRenamed :: IsParsed Renamed IsTypechecked :: IsParsed Typechecked instance PassC Parsed where getPass = IsParsed ...etc... Now we could sweep away all those OutputableX classes, replacing them with dynamic tests on the singletons IsParsed etc. This would have advantages: - Probably faster: there's a dynamic test, but many fewer dictionary arguments and higher-order function dispatch - Only one dictionary to pass; programming is easier. The big downside is that it's not extensible: it works only because we know the three cases. But the "Trees that Grow" story really doesn't scale well to pretty-printing: so maybe we should just give up on that? -------------- next part -------------- An HTML attachment was scrubbed... URL: From sh.najd at gmail.com Fri Jul 28 11:19:33 2017 From: sh.najd at gmail.com (Shayan Najd) Date: Fri, 28 Jul 2017 13:19:33 +0200 Subject: Operating on HsSyn In-Reply-To: References: Message-ID: Before all this, we may need to discuss a bit about the intended semantics of `Outputable`: does it need to print `PostRn`, or `PostTc` fields; or `Out` suffixed constructors? If not, then we only need to write a set of instances for the base growable AST, once and for all. Such instances will be polymorphic on the extension descriptor `p`, and do not need to mention the constraints like `(PostRn p (IdP p)`, since these are just extensions and not part of the base growable AST. Or, am I missing something about the intended semantics of `Outputable`? You write So today we never print these annotations, to avoid bloating the instance > contexts, which can be painful. > I have been under the impression that we don't even want to print those. Of course, there are scenarios (like `Show` instances) where we do want to write compositional / generic functions that take into account the extensions. Here is my abstract overview of the scenario, that may help the discussion. Consider data types `A`, `B`, and `C` (say, one AST datatype per compiler phase) that are defined as extensions to a base datatype `T`: > A = T XA > B = T XB > C = T XC where `X*`s are extension descriptors. Now, say we want to a define functions `f_A`, `f_B`, and `f_C` over `A`, `B`, and `C`. We have two main alternatives: (a) either we write these (manually or using the deriving mechanism) separately (b) or we write a generic / parametric function `g` over `T`, and reuse that to define `f_*`s Of course, (b) is preferable in theory , but not always possible or preferable in practice. In which case, we can always resort to (a). The more varying are the definitions of `f_A`, `f_B`, and `f_C` the more parametric should `g` get, as this is the case for any generic function. With a correct design, I believe, these are all independent of Trees that Grow story itself: we are now not only trying to reuse data types, and functions agnostic towards extensions (pretty printers in my view of their semantics), but also reuse functions with parametric / varying behaviour with respect to extensions. /Shayan On Fri, Jul 28, 2017 at 10:18 AM, Simon Peyton Jones wrote: > Devs, > > > > Shayan is working away on “Trees that grow”… do keep it on your radar: > > > > *To:* ghc-devs > *Sent:* 25 May 2017 23:49 > > Do take a look at this: > > > > · We propose to re-engineer HsSyn itself. This will touch a *lot* > of code. > > · But it’s very neat, and will bring big long-term advantages > > · And we can do it a bit at a time > > > > The wiki page https://ghc.haskell.org/trac/ghc/wiki/ > ImplementingTreesThatGrow has the details. It’s entirely an internal > change, not a change to GHC’s specification, so it’s independent of the GHC > proposals process. But I’d value the opinion of other GHC devs > > > > Meanwhile I have a question. When pretty-printing HsSyn we often have a > situation like this: > > > > data Pass = Parsed | Renamed | Typechecked > > > > data HsExpr (p :: Pass) = HsVar (IdP p) | .... > > > > type famliy IdP p where > > IdP Parsed = RdrName > > IdP Renamed = Name > > IdP Typechecked = Id > > > > instance (Outputable (IdP p)) => Outputable (HsExpr p) where > > ppr (HsVar v) = ppr v > > > > The (ppr v) requires (Outputable (IdP p)), hence the context. > > > > Moreover, and more seriously, there are things we just can't pretty-print > > right now. For example, HsExpr has this data constructor: > > > > data HsExpr p = ... > > | OpApp (LHsExpr p) > > (LHsExpr p) > > (PostRn p Fixity) > > (LHsExpr p) > > > > To pretty-print the third argument, we'd need to add > > > > instance (Outputable (IdP p), > > Outputable (PostRn p Fixity)) -- New > > => Outputable (HsExpr p) where > > ppr (HsVar v) = ppr v > > > > and that gets onerous. *So today we never print these annotations*, to > avoid bloating the instance contexts, which can be painful. It bit me > yesterday. > > > > We have bitten that bullet for the Data class: look at HsExtension.DataId, > which abbreviates the long list of dictionaries: > > > > type DataId p = > > ( Data p > > , ForallX Data p > > , Data (NameOrRdrName (IdP p)) > > , Data (IdP p) > > , Data (PostRn p (IdP p)) > > , Data (PostRn p (Located Name)) > > , Data (PostRn p Bool) > > , Data (PostRn p Fixity) > > ,..and nine more... ) > > > > Let me note in passing that [wiki:QuantifiedContexts > ] would make > this somewhat shorter > > > > type DataId p = > > ( Data p > > , ForallX Data p > > , Data (NameOrRdrName (IdP p)) > > , Data (IdP p) > > , forall t. Data t => Data (PostRn p t)) > > > > But we still need one item in this list for each type function, > > and I am worried about how this scales to the > > [wiki:ImplementingTreesThatGrow > ] story, > when we have a type > > function for each data constructor -- and there are a *lot* of data > > constructors. > > > > *So I have four questions* > > > > 1. I think we should probably use a superclass instead of a type > synonym > > > > class (Data p, ForallX Data p, ....) => DataId p where {} > > > > Why? Only one argument to pass, and to pass on to successive calls. I > see no downside. > > > > 1. Shall we treat Outputable like Data? (I.e. make an abbreviation > for a long list of Outputable instances and use it everywhere) > > 2. I thought of another way to do it (pass a token); see below > > > > 1. Are there any other ways? > > > > > > *Token passing idea.* > > > > Perhaps instead of passing lots of functions, we pass a singleton token > > that encodes the pass, like this: > > > > instance (PassC p) => Outputable (HsExpr p) where > > ppr (HsVar v) = case getPass :: IsPass p of > > IsParsed -> ppr v > > IsRenamed -> ppr v > > IsTypechecked -> ppr v > > > > The three ppr's are at different types, of course; that's the point. > > The infrastructure is something like > > > > class PassC p where > > getPass :: IsPass p > > > > data IsPass p where > > IsParsed :: IsPass Parsed > > IsRenamed :: IsParsed Renamed > > IsTypechecked :: IsParsed Typechecked > > > > instance PassC Parsed where getPass = IsParsed > > ...etc... > > > > Now we could sweep away all those OutputableX classes, > > replacing them with dynamic tests on the singletons IsParsed etc. > > This would have advantages: > > > > - Probably faster: there's a dynamic test, but many fewer dictionary > > arguments and higher-order function dispatch > > > > - Only one dictionary to pass; programming is easier. > > > > The big downside is that it's not extensible: it works only because > > we know the three cases. But the "Trees that Grow" story really doesn't > > scale well to pretty-printing: so maybe we should just give up on that? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Fri Jul 28 12:36:03 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 28 Jul 2017 12:36:03 +0000 Subject: Operating on HsSyn In-Reply-To: References: Message-ID: I have been under the impression that we don't even want to print those. On the contrary, inside GHC I /do/ want to print them. Otherwise how can I see what the renamer has done? Simon From: Shayan Najd [mailto:sh.najd at gmail.com] Sent: 28 July 2017 12:20 To: Simon Peyton Jones Cc: ghc-devs at haskell.org; Alan & Kim Zimmerman Subject: Re: Operating on HsSyn Before all this, we may need to discuss a bit about the intended semantics of `Outputable`: does it need to print `PostRn`, or `PostTc` fields; or `Out` suffixed constructors? If not, then we only need to write a set of instances for the base growable AST, once and for all. Such instances will be polymorphic on the extension descriptor `p`, and do not need to mention the constraints like `(PostRn p (IdP p)`, since these are just extensions and not part of the base growable AST. Or, am I missing something about the intended semantics of `Outputable`? You write So today we never print these annotations, to avoid bloating the instance contexts, which can be painful. I have been under the impression that we don't even want to print those. Of course, there are scenarios (like `Show` instances) where we do want to write compositional / generic functions that take into account the extensions. Here is my abstract overview of the scenario, that may help the discussion. Consider data types `A`, `B`, and `C` (say, one AST datatype per compiler phase) that are defined as extensions to a base datatype `T`: > A = T XA > B = T XB > C = T XC where `X*`s are extension descriptors. Now, say we want to a define functions `f_A`, `f_B`, and `f_C` over `A`, `B`, and `C`. We have two main alternatives: (a) either we write these (manually or using the deriving mechanism) separately (b) or we write a generic / parametric function `g` over `T`, and reuse that to define `f_*`s Of course, (b) is preferable in theory , but not always possible or preferable in practice. In which case, we can always resort to (a). The more varying are the definitions of `f_A`, `f_B`, and `f_C` the more parametric should `g` get, as this is the case for any generic function. With a correct design, I believe, these are all independent of Trees that Grow story itself: we are now not only trying to reuse data types, and functions agnostic towards extensions (pretty printers in my view of their semantics), but also reuse functions with parametric / varying behaviour with respect to extensions. /Shayan On Fri, Jul 28, 2017 at 10:18 AM, Simon Peyton Jones > wrote: Devs, Shayan is working away on “Trees that grow”… do keep it on your radar: To: ghc-devs Sent: 25 May 2017 23:49 Do take a look at this: • We propose to re-engineer HsSyn itself. This will touch a lot of code. • But it’s very neat, and will bring big long-term advantages • And we can do it a bit at a time The wiki page https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow has the details. It’s entirely an internal change, not a change to GHC’s specification, so it’s independent of the GHC proposals process. But I’d value the opinion of other GHC devs Meanwhile I have a question. When pretty-printing HsSyn we often have a situation like this: data Pass = Parsed | Renamed | Typechecked data HsExpr (p :: Pass) = HsVar (IdP p) | .... type famliy IdP p where IdP Parsed = RdrName IdP Renamed = Name IdP Typechecked = Id instance (Outputable (IdP p)) => Outputable (HsExpr p) where ppr (HsVar v) = ppr v The (ppr v) requires (Outputable (IdP p)), hence the context. Moreover, and more seriously, there are things we just can't pretty-print right now. For example, HsExpr has this data constructor: data HsExpr p = ... | OpApp (LHsExpr p) (LHsExpr p) (PostRn p Fixity) (LHsExpr p) To pretty-print the third argument, we'd need to add instance (Outputable (IdP p), Outputable (PostRn p Fixity)) -- New => Outputable (HsExpr p) where ppr (HsVar v) = ppr v and that gets onerous. So today we never print these annotations, to avoid bloating the instance contexts, which can be painful. It bit me yesterday. We have bitten that bullet for the Data class: look at HsExtension.DataId, which abbreviates the long list of dictionaries: type DataId p = ( Data p , ForallX Data p , Data (NameOrRdrName (IdP p)) , Data (IdP p) , Data (PostRn p (IdP p)) , Data (PostRn p (Located Name)) , Data (PostRn p Bool) , Data (PostRn p Fixity) ,..and nine more... ) Let me note in passing that [wiki:QuantifiedContexts] would make this somewhat shorter type DataId p = ( Data p , ForallX Data p , Data (NameOrRdrName (IdP p)) , Data (IdP p) , forall t. Data t => Data (PostRn p t)) But we still need one item in this list for each type function, and I am worried about how this scales to the [wiki:ImplementingTreesThatGrow] story, when we have a type function for each data constructor -- and there are a lot of data constructors. So I have four questions 1. I think we should probably use a superclass instead of a type synonym class (Data p, ForallX Data p, ....) => DataId p where {} Why? Only one argument to pass, and to pass on to successive calls. I see no downside. 1. Shall we treat Outputable like Data? (I.e. make an abbreviation for a long list of Outputable instances and use it everywhere) 2. I thought of another way to do it (pass a token); see below 1. Are there any other ways? Token passing idea. Perhaps instead of passing lots of functions, we pass a singleton token that encodes the pass, like this: instance (PassC p) => Outputable (HsExpr p) where ppr (HsVar v) = case getPass :: IsPass p of IsParsed -> ppr v IsRenamed -> ppr v IsTypechecked -> ppr v The three ppr's are at different types, of course; that's the point. The infrastructure is something like class PassC p where getPass :: IsPass p data IsPass p where IsParsed :: IsPass Parsed IsRenamed :: IsParsed Renamed IsTypechecked :: IsParsed Typechecked instance PassC Parsed where getPass = IsParsed ...etc... Now we could sweep away all those OutputableX classes, replacing them with dynamic tests on the singletons IsParsed etc. This would have advantages: - Probably faster: there's a dynamic test, but many fewer dictionary arguments and higher-order function dispatch - Only one dictionary to pass; programming is easier. The big downside is that it's not extensible: it works only because we know the three cases. But the "Trees that Grow" story really doesn't scale well to pretty-printing: so maybe we should just give up on that? -------------- next part -------------- An HTML attachment was scrubbed... URL: From sh.najd at gmail.com Fri Jul 28 14:32:13 2017 From: sh.najd at gmail.com (Shayan Najd) Date: Fri, 28 Jul 2017 16:32:13 +0200 Subject: Operating on HsSyn In-Reply-To: References: Message-ID: > > On the contrary, inside GHC I /do/ want to print them. Otherwise how can I > see what the renamer has done? Right. So if I understand correctly, with this semantics, `Outputable` is somewhere between pretty printing as often used in program manipulation libraries (like Haskell-Src-Exts (HSE)) which is closer to syntax, and `Show` which is closer to Haskell representation. (There are also "exact printers" (as in HSE) that are even closer to syntax in some sense.) Often, pretty printers generate only grammatically valid terms, not the ones polluted with extra annotations (hence grammatically invalid), e.g., what is the grammatically valid form of `OpApp` printed via `Outputable` that includes the fixity annotation. If I recall correctly, we have briefly studied these in the past summer, we came up with some roundtrip correctness criteria, like the following (bar error handling; assume valid input): (parser . prettyPrint . parser) = id [paging in Jacques] The reason I am trying to flesh out the semantics is the /big/ gains on code reuse later on in the process: one does not need to define a separate pretty printing library for Haskell syntax, and can reuse the well-tested and well-maintained one in GHC. Reformulating part of your concern, based on my understanding (if I may), the questions is: what is the proper design of an "outputer" (debug-printer?) where /annotated/ terms can be pretty-printed including any printable (pretty?showable?) annotations. In particular, we may want to take advantage of extensibility of data types for this. Am I far off? Note: with proper design, an extensible debug-printer can still subsume corresponding pretty-printers. On Fri, Jul 28, 2017 at 2:36 PM, Simon Peyton Jones wrote: > I have been under the impression that we don't even want to print those. > > On the contrary, inside GHC I /do/ want to print them. Otherwise how can I > see what the renamer has done? > > > > Simon > > > > *From:* Shayan Najd [mailto:sh.najd at gmail.com] > *Sent:* 28 July 2017 12:20 > *To:* Simon Peyton Jones > *Cc:* ghc-devs at haskell.org; Alan & Kim Zimmerman > *Subject:* Re: Operating on HsSyn > > > > Before all this, we may need to discuss a bit about the intended semantics > of > > `Outputable`: does it need to print `PostRn`, or `PostTc` fields; or `Out` > > suffixed constructors? If not, then we only need to write a set of > instances > > for the base growable AST, once and for all. Such instances will be > polymorphic > > on the extension descriptor `p`, and do not need to mention the > constraints like > > `(PostRn p (IdP p)`, since these are just extensions and not part of the > base > > growable AST. Or, am I missing something about the intended semantics of > > `Outputable`? > > > > You write > > > > So today we never print these annotations, to avoid bloating the instance > contexts, which can be painful. > > > > I have been under the impression that we don't even want to print those. > > > > Of course, there are scenarios (like `Show` instances) where we do want to > write > > compositional / generic functions that take into account the extensions. > > Here is my abstract overview of the scenario, that may help the discussion. > > Consider data types `A`, `B`, and `C` (say, one AST datatype per compiler > phase) that > > are defined as extensions to a base datatype `T`: > > > > > A = T XA > > > B = T XB > > > C = T XC > > > > where `X*`s are extension descriptors. > > Now, say we want to a define functions `f_A`, `f_B`, and `f_C` over `A`, ` > B`, and `C`. > > We have two main alternatives: > > (a) either we write these (manually or using the deriving mechanism) > separately > > (b) or we write a generic / parametric function `g` over `T`, and reuse > that to define `f_*`s > > > > Of course, (b) is preferable in theory , but not always possible or > preferable in practice. > > In which case, we can always resort to (a). > > The more varying are the definitions of `f_A`, `f_B`, and `f_C` the more > parametric should > > `g` get, as this is the case for any generic function. > > > > With a correct design, I believe, these are all independent of Trees that > Grow story itself: > > we are now not only trying to reuse data types, and functions agnostic > towards extensions > > (pretty printers in my view of their semantics), but also reuse functions > with parametric / > > varying behaviour with respect to extensions. > > > > /Shayan > > > > > > > > On Fri, Jul 28, 2017 at 10:18 AM, Simon Peyton Jones < > simonpj at microsoft.com> wrote: > > Devs, > > > > Shayan is working away on “Trees that grow”… do keep it on your radar: > > > > *To:* ghc-devs > *Sent:* 25 May 2017 23:49 > > Do take a look at this: > > > > · We propose to re-engineer HsSyn itself. This will touch a *lot* > of code. > > · But it’s very neat, and will bring big long-term advantages > > · And we can do it a bit at a time > > > > The wiki page https://ghc.haskell.org/trac/ghc/wiki/ > ImplementingTreesThatGrow has the details. It’s entirely an internal > change, not a change to GHC’s specification, so it’s independent of the GHC > proposals process. But I’d value the opinion of other GHC devs > > > > Meanwhile I have a question. When pretty-printing HsSyn we often have a > situation like this: > > > > data Pass = Parsed | Renamed | Typechecked > > > > data HsExpr (p :: Pass) = HsVar (IdP p) | .... > > > > type famliy IdP p where > > IdP Parsed = RdrName > > IdP Renamed = Name > > IdP Typechecked = Id > > > > instance (Outputable (IdP p)) => Outputable (HsExpr p) where > > ppr (HsVar v) = ppr v > > > > The (ppr v) requires (Outputable (IdP p)), hence the context. > > > > Moreover, and more seriously, there are things we just can't pretty-print > > right now. For example, HsExpr has this data constructor: > > > > data HsExpr p = ... > > | OpApp (LHsExpr p) > > (LHsExpr p) > > (PostRn p Fixity) > > (LHsExpr p) > > > > To pretty-print the third argument, we'd need to add > > > > instance (Outputable (IdP p), > > Outputable (PostRn p Fixity)) -- New > > => Outputable (HsExpr p) where > > ppr (HsVar v) = ppr v > > > > and that gets onerous. *So today we never print these annotations*, to > avoid bloating the instance contexts, which can be painful. It bit me > yesterday. > > > > We have bitten that bullet for the Data class: look at HsExtension.DataId, > which abbreviates the long list of dictionaries: > > > > type DataId p = > > ( Data p > > , ForallX Data p > > , Data (NameOrRdrName (IdP p)) > > , Data (IdP p) > > , Data (PostRn p (IdP p)) > > , Data (PostRn p (Located Name)) > > , Data (PostRn p Bool) > > , Data (PostRn p Fixity) > > ,..and nine more... ) > > > > Let me note in passing that [wiki:QuantifiedContexts > ] would make > this somewhat shorter > > > > type DataId p = > > ( Data p > > , ForallX Data p > > , Data (NameOrRdrName (IdP p)) > > , Data (IdP p) > > , forall t. Data t => Data (PostRn p t)) > > > > But we still need one item in this list for each type function, > > and I am worried about how this scales to the > > [wiki:ImplementingTreesThatGrow > ] story, > when we have a type > > function for each data constructor -- and there are a *lot* of data > > constructors. > > > > *So I have four questions* > > > > 1. I think we should probably use a superclass instead of a type > synonym > > > > class (Data p, ForallX Data p, ....) => DataId p where {} > > > > Why? Only one argument to pass, and to pass on to successive calls. I > see no downside. > > > > 1. Shall we treat Outputable like Data? (I.e. make an abbreviation > for a long list of Outputable instances and use it everywhere) > 2. I thought of another way to do it (pass a token); see below > > > > 1. Are there any other ways? > > > > > > *Token passing idea.* > > > > Perhaps instead of passing lots of functions, we pass a singleton token > > that encodes the pass, like this: > > > > instance (PassC p) => Outputable (HsExpr p) where > > ppr (HsVar v) = case getPass :: IsPass p of > > IsParsed -> ppr v > > IsRenamed -> ppr v > > IsTypechecked -> ppr v > > > > The three ppr's are at different types, of course; that's the point. > > The infrastructure is something like > > > > class PassC p where > > getPass :: IsPass p > > > > data IsPass p where > > IsParsed :: IsPass Parsed > > IsRenamed :: IsParsed Renamed > > IsTypechecked :: IsParsed Typechecked > > > > instance PassC Parsed where getPass = IsParsed > > ...etc... > > > > Now we could sweep away all those OutputableX classes, > > replacing them with dynamic tests on the singletons IsParsed etc. > > This would have advantages: > > > > - Probably faster: there's a dynamic test, but many fewer dictionary > > arguments and higher-order function dispatch > > > > - Only one dictionary to pass; programming is easier. > > > > The big downside is that it's not extensible: it works only because > > we know the three cases. But the "Trees that Grow" story really doesn't > > scale well to pretty-printing: so maybe we should just give up on that? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sh.najd at gmail.com Fri Jul 28 17:38:11 2017 From: sh.najd at gmail.com (Shayan Najd) Date: Fri, 28 Jul 2017 19:38:11 +0200 Subject: Operating on HsSyn In-Reply-To: References: Message-ID: by (parser . prettyPrint . parser) = id I meant (prettyPrint . parser . prettyPrint) = id for a valid input. On Fri, Jul 28, 2017 at 4:32 PM, Shayan Najd wrote: > On the contrary, inside GHC I /do/ want to print them. Otherwise how can I >> see what the renamer has done? > > > Right. So if I understand correctly, with this semantics, `Outputable` is > somewhere between pretty printing as often used in program manipulation > libraries (like Haskell-Src-Exts (HSE)) which is closer to syntax, and > `Show` which is closer to Haskell representation. > (There are also "exact printers" (as in HSE) that are even closer to > syntax in some sense.) > Often, pretty printers generate only grammatically valid terms, not the > ones polluted with extra annotations (hence grammatically invalid), e.g., > what is the grammatically valid form of `OpApp` printed via `Outputable` > that includes the fixity annotation. > > If I recall correctly, we have briefly studied these in the past summer, > we came up with some roundtrip correctness criteria, like the following > (bar error handling; assume valid input): > > (parser . prettyPrint . parser) = id > > [paging in Jacques] > > The reason I am trying to flesh out the semantics is the /big/ gains on > code reuse later on in the process: one does not need to define a separate > pretty printing library for Haskell syntax, and can reuse the well-tested > and well-maintained one in GHC. > > Reformulating part of your concern, based on my understanding (if I may), > the questions is: what is the proper design of an "outputer" > (debug-printer?) where /annotated/ terms can be pretty-printed including > any printable (pretty?showable?) annotations. > In particular, we may want to take advantage of extensibility of data > types for this. > Am I far off? > > Note: with proper design, an extensible debug-printer can still subsume > corresponding pretty-printers. > > > On Fri, Jul 28, 2017 at 2:36 PM, Simon Peyton Jones > wrote: > >> I have been under the impression that we don't even want to print those. >> >> On the contrary, inside GHC I /do/ want to print them. Otherwise how can >> I see what the renamer has done? >> >> >> >> Simon >> >> >> >> *From:* Shayan Najd [mailto:sh.najd at gmail.com] >> *Sent:* 28 July 2017 12:20 >> *To:* Simon Peyton Jones >> *Cc:* ghc-devs at haskell.org; Alan & Kim Zimmerman >> *Subject:* Re: Operating on HsSyn >> >> >> >> Before all this, we may need to discuss a bit about the intended >> semantics of >> >> `Outputable`: does it need to print `PostRn`, or `PostTc` fields; or `Out` >> >> suffixed constructors? If not, then we only need to write a set of >> instances >> >> for the base growable AST, once and for all. Such instances will be >> polymorphic >> >> on the extension descriptor `p`, and do not need to mention the >> constraints like >> >> `(PostRn p (IdP p)`, since these are just extensions and not part of the >> base >> >> growable AST. Or, am I missing something about the intended semantics of >> >> `Outputable`? >> >> >> >> You write >> >> >> >> So today we never print these annotations, to avoid bloating the instance >> contexts, which can be painful. >> >> >> >> I have been under the impression that we don't even want to print those. >> >> >> >> Of course, there are scenarios (like `Show` instances) where we do want >> to write >> >> compositional / generic functions that take into account the extensions. >> >> Here is my abstract overview of the scenario, that may help the >> discussion. >> >> Consider data types `A`, `B`, and `C` (say, one AST datatype per compiler >> phase) that >> >> are defined as extensions to a base datatype `T`: >> >> >> >> > A = T XA >> >> > B = T XB >> >> > C = T XC >> >> >> >> where `X*`s are extension descriptors. >> >> Now, say we want to a define functions `f_A`, `f_B`, and `f_C` over `A`, >> `B`, and `C`. >> >> We have two main alternatives: >> >> (a) either we write these (manually or using the deriving mechanism) >> separately >> >> (b) or we write a generic / parametric function `g` over `T`, and reuse >> that to define `f_*`s >> >> >> >> Of course, (b) is preferable in theory , but not always possible or >> preferable in practice. >> >> In which case, we can always resort to (a). >> >> The more varying are the definitions of `f_A`, `f_B`, and `f_C` the more >> parametric should >> >> `g` get, as this is the case for any generic function. >> >> >> >> With a correct design, I believe, these are all independent of Trees that >> Grow story itself: >> >> we are now not only trying to reuse data types, and functions agnostic >> towards extensions >> >> (pretty printers in my view of their semantics), but also reuse functions >> with parametric / >> >> varying behaviour with respect to extensions. >> >> >> >> /Shayan >> >> >> >> >> >> >> >> On Fri, Jul 28, 2017 at 10:18 AM, Simon Peyton Jones < >> simonpj at microsoft.com> wrote: >> >> Devs, >> >> >> >> Shayan is working away on “Trees that grow”… do keep it on your radar: >> >> >> >> *To:* ghc-devs >> *Sent:* 25 May 2017 23:49 >> >> Do take a look at this: >> >> >> >> · We propose to re-engineer HsSyn itself. This will touch a >> *lot* of code. >> >> · But it’s very neat, and will bring big long-term advantages >> >> · And we can do it a bit at a time >> >> >> >> The wiki page https://ghc.haskell.org/trac/g >> hc/wiki/ImplementingTreesThatGrow has the details. It’s entirely an >> internal change, not a change to GHC’s specification, so it’s independent >> of the GHC proposals process. But I’d value the opinion of other GHC devs >> >> >> >> Meanwhile I have a question. When pretty-printing HsSyn we often have a >> situation like this: >> >> >> >> data Pass = Parsed | Renamed | Typechecked >> >> >> >> data HsExpr (p :: Pass) = HsVar (IdP p) | .... >> >> >> >> type famliy IdP p where >> >> IdP Parsed = RdrName >> >> IdP Renamed = Name >> >> IdP Typechecked = Id >> >> >> >> instance (Outputable (IdP p)) => Outputable (HsExpr p) where >> >> ppr (HsVar v) = ppr v >> >> >> >> The (ppr v) requires (Outputable (IdP p)), hence the context. >> >> >> >> Moreover, and more seriously, there are things we just can't pretty-print >> >> right now. For example, HsExpr has this data constructor: >> >> >> >> data HsExpr p = ... >> >> | OpApp (LHsExpr p) >> >> (LHsExpr p) >> >> (PostRn p Fixity) >> >> (LHsExpr p) >> >> >> >> To pretty-print the third argument, we'd need to add >> >> >> >> instance (Outputable (IdP p), >> >> Outputable (PostRn p Fixity)) -- New >> >> => Outputable (HsExpr p) where >> >> ppr (HsVar v) = ppr v >> >> >> >> and that gets onerous. *So today we never print these annotations*, to >> avoid bloating the instance contexts, which can be painful. It bit me >> yesterday. >> >> >> >> We have bitten that bullet for the Data class: look at >> HsExtension.DataId, which abbreviates the long list of dictionaries: >> >> >> >> type DataId p = >> >> ( Data p >> >> , ForallX Data p >> >> , Data (NameOrRdrName (IdP p)) >> >> , Data (IdP p) >> >> , Data (PostRn p (IdP p)) >> >> , Data (PostRn p (Located Name)) >> >> , Data (PostRn p Bool) >> >> , Data (PostRn p Fixity) >> >> ,..and nine more... ) >> >> >> >> Let me note in passing that [wiki:QuantifiedContexts >> ] would make >> this somewhat shorter >> >> >> >> type DataId p = >> >> ( Data p >> >> , ForallX Data p >> >> , Data (NameOrRdrName (IdP p)) >> >> , Data (IdP p) >> >> , forall t. Data t => Data (PostRn p t)) >> >> >> >> But we still need one item in this list for each type function, >> >> and I am worried about how this scales to the >> >> [wiki:ImplementingTreesThatGrow >> ] >> story, when we have a type >> >> function for each data constructor -- and there are a *lot* of data >> >> constructors. >> >> >> >> *So I have four questions* >> >> >> >> 1. I think we should probably use a superclass instead of a type >> synonym >> >> >> >> class (Data p, ForallX Data p, ....) => DataId p where {} >> >> >> >> Why? Only one argument to pass, and to pass on to successive calls. I >> see no downside. >> >> >> >> 1. Shall we treat Outputable like Data? (I.e. make an abbreviation >> for a long list of Outputable instances and use it everywhere) >> 2. I thought of another way to do it (pass a token); see below >> >> >> >> 1. Are there any other ways? >> >> >> >> >> >> *Token passing idea.* >> >> >> >> Perhaps instead of passing lots of functions, we pass a singleton token >> >> that encodes the pass, like this: >> >> >> >> instance (PassC p) => Outputable (HsExpr p) where >> >> ppr (HsVar v) = case getPass :: IsPass p of >> >> IsParsed -> ppr v >> >> IsRenamed -> ppr v >> >> IsTypechecked -> ppr v >> >> >> >> The three ppr's are at different types, of course; that's the point. >> >> The infrastructure is something like >> >> >> >> class PassC p where >> >> getPass :: IsPass p >> >> >> >> data IsPass p where >> >> IsParsed :: IsPass Parsed >> >> IsRenamed :: IsParsed Renamed >> >> IsTypechecked :: IsParsed Typechecked >> >> >> >> instance PassC Parsed where getPass = IsParsed >> >> ...etc... >> >> >> >> Now we could sweep away all those OutputableX classes, >> >> replacing them with dynamic tests on the singletons IsParsed etc. >> >> This would have advantages: >> >> >> >> - Probably faster: there's a dynamic test, but many fewer dictionary >> >> arguments and higher-order function dispatch >> >> >> >> - Only one dictionary to pass; programming is easier. >> >> >> >> The big downside is that it's not extensible: it works only because >> >> we know the three cases. But the "Trees that Grow" story really doesn't >> >> scale well to pretty-printing: so maybe we should just give up on that? >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.zimm at gmail.com Fri Jul 28 17:49:04 2017 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Fri, 28 Jul 2017 19:49:04 +0200 Subject: Operating on HsSyn In-Reply-To: References: Message-ID: Well, in GHC as it stands now (from 8.2.1), the original formulation is correct. The current pretty printer does not reproduce layout, but reparsing a pretty printed ParsedSource will faithfully reproduce the original ParsedSource (except for the Locations). This is useful for constructing hsSyn fragments programmatically and generating usable source from them. I am hoping (intending) that a future version will allow the other formulation too. Alan On 28 July 2017 at 19:38, Shayan Najd wrote: > by > > (parser . prettyPrint . parser) = id > > > I meant > > (prettyPrint . parser . prettyPrint) = id > > for a valid input. > > > On Fri, Jul 28, 2017 at 4:32 PM, Shayan Najd wrote: > >> On the contrary, inside GHC I /do/ want to print them. Otherwise how can >>> I see what the renamer has done? >> >> >> Right. So if I understand correctly, with this semantics, `Outputable` is >> somewhere between pretty printing as often used in program manipulation >> libraries (like Haskell-Src-Exts (HSE)) which is closer to syntax, and >> `Show` which is closer to Haskell representation. >> (There are also "exact printers" (as in HSE) that are even closer to >> syntax in some sense.) >> Often, pretty printers generate only grammatically valid terms, not the >> ones polluted with extra annotations (hence grammatically invalid), e.g., >> what is the grammatically valid form of `OpApp` printed via `Outputable` >> that includes the fixity annotation. >> >> If I recall correctly, we have briefly studied these in the past summer, >> we came up with some roundtrip correctness criteria, like the following >> (bar error handling; assume valid input): >> >> (parser . prettyPrint . parser) = id >> >> [paging in Jacques] >> >> The reason I am trying to flesh out the semantics is the /big/ gains on >> code reuse later on in the process: one does not need to define a separate >> pretty printing library for Haskell syntax, and can reuse the well-tested >> and well-maintained one in GHC. >> >> Reformulating part of your concern, based on my understanding (if I may), >> the questions is: what is the proper design of an "outputer" >> (debug-printer?) where /annotated/ terms can be pretty-printed including >> any printable (pretty?showable?) annotations. >> In particular, we may want to take advantage of extensibility of data >> types for this. >> Am I far off? >> >> Note: with proper design, an extensible debug-printer can still subsume >> corresponding pretty-printers. >> >> >> On Fri, Jul 28, 2017 at 2:36 PM, Simon Peyton Jones < >> simonpj at microsoft.com> wrote: >> >>> I have been under the impression that we don't even want to print those. >>> >>> On the contrary, inside GHC I /do/ want to print them. Otherwise how can >>> I see what the renamer has done? >>> >>> >>> >>> Simon >>> >>> >>> >>> *From:* Shayan Najd [mailto:sh.najd at gmail.com] >>> *Sent:* 28 July 2017 12:20 >>> *To:* Simon Peyton Jones >>> *Cc:* ghc-devs at haskell.org; Alan & Kim Zimmerman >>> *Subject:* Re: Operating on HsSyn >>> >>> >>> >>> Before all this, we may need to discuss a bit about the intended >>> semantics of >>> >>> `Outputable`: does it need to print `PostRn`, or `PostTc` fields; or >>> `Out` >>> >>> suffixed constructors? If not, then we only need to write a set of >>> instances >>> >>> for the base growable AST, once and for all. Such instances will be >>> polymorphic >>> >>> on the extension descriptor `p`, and do not need to mention the >>> constraints like >>> >>> `(PostRn p (IdP p)`, since these are just extensions and not part of the >>> base >>> >>> growable AST. Or, am I missing something about the intended semantics of >>> >>> `Outputable`? >>> >>> >>> >>> You write >>> >>> >>> >>> So today we never print these annotations, to avoid bloating the >>> instance contexts, which can be painful. >>> >>> >>> >>> I have been under the impression that we don't even want to print those. >>> >>> >>> >>> Of course, there are scenarios (like `Show` instances) where we do want >>> to write >>> >>> compositional / generic functions that take into account the extensions. >>> >>> Here is my abstract overview of the scenario, that may help the >>> discussion. >>> >>> Consider data types `A`, `B`, and `C` (say, one AST datatype per >>> compiler phase) that >>> >>> are defined as extensions to a base datatype `T`: >>> >>> >>> >>> > A = T XA >>> >>> > B = T XB >>> >>> > C = T XC >>> >>> >>> >>> where `X*`s are extension descriptors. >>> >>> Now, say we want to a define functions `f_A`, `f_B`, and `f_C` over `A`, >>> `B`, and `C`. >>> >>> We have two main alternatives: >>> >>> (a) either we write these (manually or using the deriving mechanism) >>> separately >>> >>> (b) or we write a generic / parametric function `g` over `T`, and reuse >>> that to define `f_*`s >>> >>> >>> >>> Of course, (b) is preferable in theory , but not always possible or >>> preferable in practice. >>> >>> In which case, we can always resort to (a). >>> >>> The more varying are the definitions of `f_A`, `f_B`, and `f_C` the more >>> parametric should >>> >>> `g` get, as this is the case for any generic function. >>> >>> >>> >>> With a correct design, I believe, these are all independent of Trees >>> that Grow story itself: >>> >>> we are now not only trying to reuse data types, and functions agnostic >>> towards extensions >>> >>> (pretty printers in my view of their semantics), but also reuse >>> functions with parametric / >>> >>> varying behaviour with respect to extensions. >>> >>> >>> >>> /Shayan >>> >>> >>> >>> >>> >>> >>> >>> On Fri, Jul 28, 2017 at 10:18 AM, Simon Peyton Jones < >>> simonpj at microsoft.com> wrote: >>> >>> Devs, >>> >>> >>> >>> Shayan is working away on “Trees that grow”… do keep it on your radar: >>> >>> >>> >>> *To:* ghc-devs >>> *Sent:* 25 May 2017 23:49 >>> >>> Do take a look at this: >>> >>> >>> >>> · We propose to re-engineer HsSyn itself. This will touch a >>> *lot* of code. >>> >>> · But it’s very neat, and will bring big long-term advantages >>> >>> · And we can do it a bit at a time >>> >>> >>> >>> The wiki page https://ghc.haskell.org/trac/g >>> hc/wiki/ImplementingTreesThatGrow has the details. It’s entirely an >>> internal change, not a change to GHC’s specification, so it’s independent >>> of the GHC proposals process. But I’d value the opinion of other GHC devs >>> >>> >>> >>> Meanwhile I have a question. When pretty-printing HsSyn we often have a >>> situation like this: >>> >>> >>> >>> data Pass = Parsed | Renamed | Typechecked >>> >>> >>> >>> data HsExpr (p :: Pass) = HsVar (IdP p) | .... >>> >>> >>> >>> type famliy IdP p where >>> >>> IdP Parsed = RdrName >>> >>> IdP Renamed = Name >>> >>> IdP Typechecked = Id >>> >>> >>> >>> instance (Outputable (IdP p)) => Outputable (HsExpr p) where >>> >>> ppr (HsVar v) = ppr v >>> >>> >>> >>> The (ppr v) requires (Outputable (IdP p)), hence the context. >>> >>> >>> >>> Moreover, and more seriously, there are things we just can't pretty-print >>> >>> right now. For example, HsExpr has this data constructor: >>> >>> >>> >>> data HsExpr p = ... >>> >>> | OpApp (LHsExpr p) >>> >>> (LHsExpr p) >>> >>> (PostRn p Fixity) >>> >>> (LHsExpr p) >>> >>> >>> >>> To pretty-print the third argument, we'd need to add >>> >>> >>> >>> instance (Outputable (IdP p), >>> >>> Outputable (PostRn p Fixity)) -- New >>> >>> => Outputable (HsExpr p) where >>> >>> ppr (HsVar v) = ppr v >>> >>> >>> >>> and that gets onerous. *So today we never print these annotations*, to >>> avoid bloating the instance contexts, which can be painful. It bit me >>> yesterday. >>> >>> >>> >>> We have bitten that bullet for the Data class: look at >>> HsExtension.DataId, which abbreviates the long list of dictionaries: >>> >>> >>> >>> type DataId p = >>> >>> ( Data p >>> >>> , ForallX Data p >>> >>> , Data (NameOrRdrName (IdP p)) >>> >>> , Data (IdP p) >>> >>> , Data (PostRn p (IdP p)) >>> >>> , Data (PostRn p (Located Name)) >>> >>> , Data (PostRn p Bool) >>> >>> , Data (PostRn p Fixity) >>> >>> ,..and nine more... ) >>> >>> >>> >>> Let me note in passing that [wiki:QuantifiedContexts >>> ] would make >>> this somewhat shorter >>> >>> >>> >>> type DataId p = >>> >>> ( Data p >>> >>> , ForallX Data p >>> >>> , Data (NameOrRdrName (IdP p)) >>> >>> , Data (IdP p) >>> >>> , forall t. Data t => Data (PostRn p t)) >>> >>> >>> >>> But we still need one item in this list for each type function, >>> >>> and I am worried about how this scales to the >>> >>> [wiki:ImplementingTreesThatGrow >>> ] >>> story, when we have a type >>> >>> function for each data constructor -- and there are a *lot* of data >>> >>> constructors. >>> >>> >>> >>> *So I have four questions* >>> >>> >>> >>> 1. I think we should probably use a superclass instead of a type >>> synonym >>> >>> >>> >>> class (Data p, ForallX Data p, ....) => DataId p where {} >>> >>> >>> >>> Why? Only one argument to pass, and to pass on to successive calls. I >>> see no downside. >>> >>> >>> >>> 1. Shall we treat Outputable like Data? (I.e. make an abbreviation >>> for a long list of Outputable instances and use it everywhere) >>> 2. I thought of another way to do it (pass a token); see below >>> >>> >>> >>> 1. Are there any other ways? >>> >>> >>> >>> >>> >>> *Token passing idea.* >>> >>> >>> >>> Perhaps instead of passing lots of functions, we pass a singleton token >>> >>> that encodes the pass, like this: >>> >>> >>> >>> instance (PassC p) => Outputable (HsExpr p) where >>> >>> ppr (HsVar v) = case getPass :: IsPass p of >>> >>> IsParsed -> ppr v >>> >>> IsRenamed -> ppr v >>> >>> IsTypechecked -> ppr v >>> >>> >>> >>> The three ppr's are at different types, of course; that's the point. >>> >>> The infrastructure is something like >>> >>> >>> >>> class PassC p where >>> >>> getPass :: IsPass p >>> >>> >>> >>> data IsPass p where >>> >>> IsParsed :: IsPass Parsed >>> >>> IsRenamed :: IsParsed Renamed >>> >>> IsTypechecked :: IsParsed Typechecked >>> >>> >>> >>> instance PassC Parsed where getPass = IsParsed >>> >>> ...etc... >>> >>> >>> >>> Now we could sweep away all those OutputableX classes, >>> >>> replacing them with dynamic tests on the singletons IsParsed etc. >>> >>> This would have advantages: >>> >>> >>> >>> - Probably faster: there's a dynamic test, but many fewer dictionary >>> >>> arguments and higher-order function dispatch >>> >>> >>> >>> - Only one dictionary to pass; programming is easier. >>> >>> >>> >>> The big downside is that it's not extensible: it works only because >>> >>> we know the three cases. But the "Trees that Grow" story really doesn't >>> >>> scale well to pretty-printing: so maybe we should just give up on that? >>> >>> >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From monkleyon at gmail.com Fri Jul 28 18:34:58 2017 From: monkleyon at gmail.com (MarLinn) Date: Fri, 28 Jul 2017 20:34:58 +0200 Subject: Operating on HsSyn In-Reply-To: References: Message-ID: > by > > (parser . prettyPrint . parser) = id > > I meant > > (prettyPrint . parser . prettyPrint) = id > > for a valid input. > Simplifying, (parser ∷ String → something), and (prettyPrint ∷ something → String). Therefore, (parser . prettyPrint . parser ∷ String → something) and (prettyPrint . parser . prettyPrint ∷ something → String). Therefore, both criteria could only apply for (something ~ String). But as pretty printing adds quotation marks, not even that is true. There are four formulations that might be applicable: 1. parser . prettyPrint ≍ id 2. prettyPrint . parser ≍ id -- ∷ String → String, useless here 3. prettyPrint . parser . prettyPrint ≍ prettyPrint 4. parser . prettyPrint . parser ≍ parser 5. Well, you could go beyond to (prettyPrint . parser . prettyPrint. parser ≍prettyPrint. parser) etc… I don't think 1 (or 2) follow from one of the last two. But 1 does imply them. So it is a stronger criterion than both, and therefore probably not the one to choose. Assuming the parser is internally consistent, 3 just says something about the internal consistency of the pretty printer, while 4 says something about the relationship of the pretty printer to the parser. Thus 4 looks like the best candidate for a criterion. Possibly with 3 as a secondary target. Cheers, MarLinn -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.zimm at gmail.com Fri Jul 28 18:43:45 2017 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Fri, 28 Jul 2017 20:43:45 +0200 Subject: Operating on HsSyn In-Reply-To: References: Message-ID: I agree. 4 is the current GHC invariant. i.e., re-parsing a pretty printed parse tree gives you back a parse tree identical to the original (ignoring SrcSpans) Alan On 28 July 2017 at 20:34, MarLinn wrote: > by > > (parser . prettyPrint . parser) = id > > I meant > > (prettyPrint . parser . prettyPrint) = id > > for a valid input. > > Simplifying, (parser ∷ String → something), and (prettyPrint ∷ something > → String). > > Therefore, (parser . prettyPrint . parser ∷ String → something) and (prettyPrint > . parser . prettyPrint ∷ something → String). > > Therefore, both criteria could only apply for (something ~ String). But > as pretty printing adds quotation marks, not even that is true. > > There are four formulations that might be applicable: > > 1. > > parser . prettyPrint ≍ id > 2. > > prettyPrint . parser ≍ id -- ∷ String → String, useless here > 3. > > prettyPrint . parser . prettyPrint ≍ prettyPrint > 4. > > parser . prettyPrint . parser ≍ parser > 5. Well, you could go beyond to (prettyPrint . parser . prettyPrint . > parser ≍ prettyPrint . parser) etc… > > I don't think 1 (or 2) follow from one of the last two. But 1 does imply > them. So it is a stronger criterion than both, and therefore probably not > the one to choose. Assuming the parser is internally consistent, 3 just > says something about the internal consistency of the pretty printer, while > 4 says something about the relationship of the pretty printer to the > parser. Thus 4 looks like the best candidate for a criterion. Possibly with > 3 as a secondary target. > > Cheers, > MarLinn > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sh.najd at gmail.com Fri Jul 28 20:11:02 2017 From: sh.najd at gmail.com (Shayan Najd) Date: Fri, 28 Jul 2017 22:11:02 +0200 Subject: Operating on HsSyn In-Reply-To: References: Message-ID: MarLinn, Thanks for correcting me, and spelling this out. I did mean what Alan mentioned: "re-parsing a pretty printed parse tree gives you back a parse tree identical to the original (ignoring SrcSpans)". As I recall, we had to go a bit further to give 'Something' some more structure to take into account things like "(ignoring SrcSpans)" (e.g., to define exact-printers, etc). Provided I have failed twice to properly recall the invariant, I refrain from trying to recall the rest tonight :) Not diverging from my point above, as far as I understand, an ideal `Outputable` machinery is going to be a bit different from the traditional pretty printers. I believe with a proper design we can even reuse `Outputable` machinery and provide it as a pretty printer for Haskell terms. It resembles the scenario in Section 3.7 compared to Section 3.6 of Trees that Grow [1]. Having said all these, we ARE diverging from the original thread, and Simon's questions. How about taking printer-design related discussion to the following wiki page (and/or a new ghc-dev thread if needed): https://ghc.haskell.org/trac/ghc/wiki/HaskellSyntaxPrinters Cheers, Shayan [1] http://www.jucs.org/jucs_23_1/trees_that_grow/jucs_23_01_0042_0062_najd.pdf On Fri, Jul 28, 2017 at 8:43 PM, Alan & Kim Zimmerman wrote: > I agree. 4 is the current GHC invariant. > > i.e., re-parsing a pretty printed parse tree gives you back a parse tree > identical to the original (ignoring SrcSpans) > > Alan > > On 28 July 2017 at 20:34, MarLinn wrote: > >> by >> >> (parser . prettyPrint . parser) = id >> >> I meant >> >> (prettyPrint . parser . prettyPrint) = id >> >> for a valid input. >> >> Simplifying, (parser ∷ String → something), and (prettyPrint ∷ something >> → String). >> >> Therefore, (parser . prettyPrint . parser ∷ String → something) and (prettyPrint >> . parser . prettyPrint ∷ something → String). >> >> Therefore, both criteria could only apply for (something ~ String). But >> as pretty printing adds quotation marks, not even that is true. >> >> There are four formulations that might be applicable: >> >> 1. >> >> parser . prettyPrint ≍ id >> 2. >> >> prettyPrint . parser ≍ id -- ∷ String → String, useless here >> 3. >> >> prettyPrint . parser . prettyPrint ≍ prettyPrint >> 4. >> >> parser . prettyPrint . parser ≍ parser >> 5. Well, you could go beyond to (prettyPrint . parser . prettyPrint . >> parser ≍ prettyPrint . parser) etc… >> >> I don't think 1 (or 2) follow from one of the last two. But 1 does imply >> them. So it is a stronger criterion than both, and therefore probably not >> the one to choose. Assuming the parser is internally consistent, 3 just >> says something about the internal consistency of the pretty printer, while >> 4 says something about the relationship of the pretty printer to the >> parser. Thus 4 looks like the best candidate for a criterion. Possibly with >> 3 as a secondary target. >> >> Cheers, >> MarLinn >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erkokl at gmail.com Sat Jul 29 06:12:32 2017 From: erkokl at gmail.com (Levent Erkok) Date: Fri, 28 Jul 2017 23:12:32 -0700 Subject: 8.2.1: Ord TyCon is gone? Message-ID: I'm trying to port some plugin code from GHC 8.0.2 to GHC 8.2.1; alas I'm getting an error suggesting that TyCon is no longer an instance of Ord: Data/SBV/Plugin/Analyze.hs:580:33: error: • No instance for (Ord TyCon) arising from a use of ‘M.lookup’ There are instances for similar types: instance Ord GHC.Types.TyCon -- Defined in ‘GHC.Classes’ • In the expression: k `M.lookup` tcMap In the expression: case k `M.lookup` tcMap of Just knd -> return knd Nothing -> unknown In a case alternative: Just k -> case k `M.lookup` tcMap of Just knd -> return knd Nothing -> unknown | 580 | Just k -> case k `M.lookup` tcMap of | ^^^^^^^^^^^^^^^^^^ I was using TyCon's as a key in a map, but that code is no longer compiling. I've looked through the release notes but couldn't find what the new mechanism is. I'd appreciate if someone can point me in the right direction regarding how to use TyCon as a map key.. Thanks, -Levent. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at nh2.me Sat Jul 29 12:45:26 2017 From: mail at nh2.me (=?UTF-8?Q?Niklas_Hamb=c3=bcchen?=) Date: Sat, 29 Jul 2017 14:45:26 +0200 Subject: 8.2.1: Ord TyCon is gone? In-Reply-To: References: Message-ID: Hi Levent, that seems to be this commit, part of the making-ghc-deterministic effort: https://ghc.haskell.org/trac/ghc/ticket/4012#comment:213 CC @niteria who might be answer your question. Niklas On 29/07/17 08:12, Levent Erkok wrote: > I'm trying to port some plugin code from GHC 8.0.2 to GHC 8.2.1; alas > I'm getting an error suggesting that TyCon is no longer an instance of Ord: > > Data/SBV/Plugin/Analyze.hs:580:33: error: > • No instance for (Ord TyCon) arising from a use of ‘M.lookup’ > There are instances for similar types: > instance Ord GHC.Types.TyCon -- Defined in ‘GHC.Classes’ > • In the expression: k `M.lookup` tcMap > In the expression: > case k `M.lookup` tcMap of > Just knd -> return knd > Nothing -> unknown > In a case alternative: > Just k > -> case k `M.lookup` tcMap of > Just knd -> return knd > Nothing -> unknown > | > 580 | Just k -> case k `M.lookup` tcMap of > | ^^^^^^^^^^^^^^^^^^ > > I was using TyCon's as a key in a map, but that code is no longer > compiling. I've looked through the release notes but couldn't find what > the new mechanism is. > > I'd appreciate if someone can point me in the right direction regarding > how to use TyCon as a map key.. From benno.fuenfstueck at gmail.com Sat Jul 29 13:07:53 2017 From: benno.fuenfstueck at gmail.com (=?UTF-8?B?QmVubm8gRsO8bmZzdMO8Y2s=?=) Date: Sat, 29 Jul 2017 13:07:53 +0000 Subject: 8.2.1: Ord TyCon is gone? In-Reply-To: References: Message-ID: Hi, Maybe you can use UniqFM for your map: https://hackage.haskell.org/package/ghc-8.2.1/docs/UniqFM.html Regards, Benno Hi Levent, > > that seems to be this commit, part of the making-ghc-deterministic effort: > > https://ghc.haskell.org/trac/ghc/ticket/4012#comment:213 > > CC @niteria who might be answer your question. > > Niklas > > On 29/07/17 08:12, Levent Erkok wrote: > > I'm trying to port some plugin code from GHC 8.0.2 to GHC 8.2.1; alas > > I'm getting an error suggesting that TyCon is no longer an instance of > Ord: > > > > Data/SBV/Plugin/Analyze.hs:580:33: error: > > • No instance for (Ord TyCon) arising from a use of ‘M.lookup’ > > There are instances for similar types: > > instance Ord GHC.Types.TyCon -- Defined in ‘GHC.Classes’ > > • In the expression: k `M.lookup` tcMap > > In the expression: > > case k `M.lookup` tcMap of > > Just knd -> return knd > > Nothing -> unknown > > In a case alternative: > > Just k > > -> case k `M.lookup` tcMap of > > Just knd -> return knd > > Nothing -> unknown > > | > > 580 | Just k -> case k `M.lookup` tcMap of > > | ^^^^^^^^^^^^^^^^^^ > > > > I was using TyCon's as a key in a map, but that code is no longer > > compiling. I've looked through the release notes but couldn't find what > > the new mechanism is. > > > > I'd appreciate if someone can point me in the right direction regarding > > how to use TyCon as a map key.. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Sat Jul 29 14:07:37 2017 From: ben at smart-cactus.org (Ben Gamari) Date: Sat, 29 Jul 2017 10:07:37 -0400 Subject: 8.2.1: Ord TyCon is gone? In-Reply-To: References: Message-ID: <87a83nnxp2.fsf@ben-laptop.smart-cactus.org> Levent Erkok writes: > I'm trying to port some plugin code from GHC 8.0.2 to GHC 8.2.1; alas I'm > getting an error suggesting that TyCon is no longer an instance of Ord: > > Data/SBV/Plugin/Analyze.hs:580:33: error: > • No instance for (Ord TyCon) arising from a use of ‘M.lookup’ > There are instances for similar types: > instance Ord GHC.Types.TyCon -- Defined in ‘GHC.Classes’ > • In the expression: k `M.lookup` tcMap > In the expression: > case k `M.lookup` tcMap of > Just knd -> return knd > Nothing -> unknown > In a case alternative: > Just k > -> case k `M.lookup` tcMap of > Just knd -> return knd > Nothing -> unknown > | > 580 | Just k -> case k `M.lookup` tcMap of > | ^^^^^^^^^^^^^^^^^^ > Hmm. I am unable to reproduce this, $ ghci λ> import Type.Reflection λ> let tc = typeRepTyCon (typeRep @Int) λ> tc == tc True Does that work for you? Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From allbery.b at gmail.com Sat Jul 29 14:13:32 2017 From: allbery.b at gmail.com (Brandon Allbery) Date: Sat, 29 Jul 2017 10:13:32 -0400 Subject: 8.2.1: Ord TyCon is gone? In-Reply-To: <87a83nnxp2.fsf@ben-laptop.smart-cactus.org> References: <87a83nnxp2.fsf@ben-laptop.smart-cactus.org> Message-ID: On Sat, Jul 29, 2017 at 10:07 AM, Ben Gamari wrote: > Hmm. I am unable to reproduce this, > > $ ghci > λ> import Type.Reflection > λ> let tc = typeRepTyCon (typeRep @Int) > λ> tc == tc > True > > Does that work for you? > Maybe I'm missing something, but doesn't that only test Eq, not Ord? -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Sat Jul 29 16:06:56 2017 From: ben at smart-cactus.org (Ben Gamari) Date: Sat, 29 Jul 2017 12:06:56 -0400 Subject: 8.2.1: Ord TyCon is gone? In-Reply-To: References: <87a83nnxp2.fsf@ben-laptop.smart-cactus.org> Message-ID: <8760ebns67.fsf@ben-laptop.smart-cactus.org> Brandon Allbery writes: > On Sat, Jul 29, 2017 at 10:07 AM, Ben Gamari wrote: > >> Hmm. I am unable to reproduce this, >> >> $ ghci >> λ> import Type.Reflection >> λ> let tc = typeRepTyCon (typeRep @Int) >> λ> tc == tc >> True >> >> Does that work for you? >> > > Maybe I'm missing something, but doesn't that only test Eq, not Ord? > Oh dear, I somehow understood that you were referring to Typeable's TyCon, not the ghc library's TyCon. Ignore my message. Indeed the TyCon Ord instance is gone to help enforce determinism within GHC. If you need a map use UniqFM. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From erkokl at gmail.com Sat Jul 29 17:44:39 2017 From: erkokl at gmail.com (Levent Erkok) Date: Sat, 29 Jul 2017 10:44:39 -0700 Subject: 8.2.1: Ord TyCon is gone? In-Reply-To: <8760ebns67.fsf@ben-laptop.smart-cactus.org> References: <87a83nnxp2.fsf@ben-laptop.smart-cactus.org> <8760ebns67.fsf@ben-laptop.smart-cactus.org> Message-ID: Thanks! Turns out I actually needed an `Ord` instance for `(TyCon, [TyCon])`, which made using `UniqFM` rather difficult, but it wasn't hard to work around the issue by using nonDetCmpUnique function from the `Unique` module. For a side project, I think it's good enough.. Cheers, -Levent. On Sat, Jul 29, 2017 at 9:06 AM, Ben Gamari wrote: > Brandon Allbery writes: > > > On Sat, Jul 29, 2017 at 10:07 AM, Ben Gamari > wrote: > > > >> Hmm. I am unable to reproduce this, > >> > >> $ ghci > >> λ> import Type.Reflection > >> λ> let tc = typeRepTyCon (typeRep @Int) > >> λ> tc == tc > >> True > >> > >> Does that work for you? > >> > > > > Maybe I'm missing something, but doesn't that only test Eq, not Ord? > > > Oh dear, I somehow understood that you were referring to Typeable's > TyCon, not the ghc library's TyCon. Ignore my message. > > Indeed the TyCon Ord instance is gone to help enforce determinism within > GHC. If you need a map use UniqFM. > > Cheers, > > - Ben > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Sat Jul 29 20:12:51 2017 From: ezyang at mit.edu (Edward Z. Yang) Date: Sat, 29 Jul 2017 16:12:51 -0400 Subject: 8.2.1: Ord TyCon is gone? In-Reply-To: References: Message-ID: <1501359129-sup-5502@sabre> Sorry about being late to the conversation, but if you need a map from Type to something, go look at TypeMap in the TrieMap module. Edward Excerpts from Levent Erkok's message of 2017-07-28 23:12:32 -0700: > I'm trying to port some plugin code from GHC 8.0.2 to GHC 8.2.1; alas I'm > getting an error suggesting that TyCon is no longer an instance of Ord: > > Data/SBV/Plugin/Analyze.hs:580:33: error: > • No instance for (Ord TyCon) arising from a use of ‘M.lookup’ > There are instances for similar types: > instance Ord GHC.Types.TyCon -- Defined in ‘GHC.Classes’ > • In the expression: k `M.lookup` tcMap > In the expression: > case k `M.lookup` tcMap of > Just knd -> return knd > Nothing -> unknown > In a case alternative: > Just k > -> case k `M.lookup` tcMap of > Just knd -> return knd > Nothing -> unknown > | > 580 | Just k -> case k `M.lookup` tcMap of > | ^^^^^^^^^^^^^^^^^^ > > I was using TyCon's as a key in a map, but that code is no longer > compiling. I've looked through the release notes but couldn't find what the > new mechanism is. > > I'd appreciate if someone can point me in the right direction regarding how > to use TyCon as a map key.. > > Thanks, > > -Levent. From sh.najd at gmail.com Mon Jul 31 00:19:01 2017 From: sh.najd at gmail.com (Shayan Najd) Date: Mon, 31 Jul 2017 02:19:01 +0200 Subject: Operating on HsSyn In-Reply-To: References: Message-ID: Simon, Back to your original questions: 1. I think we should probably use a superclass instead of a type synonym > > class (Data p, ForallX Data p, ....) => DataId p where {} > > Why? Only one argument to pass, and to pass on to successive calls. I > see no downside. Sounds good to me. I have not experimented with it yet, but I see no downside as well. Shall we treat Outputable like Data? (I.e. make an abbreviation for a long > list of Outputable instances and use it everywhere) Besides, the above point about semantics and reusing it as classical pretty-printer, I suggest a bit more fine-grained abbreviations, if we are going along this path: we define the abbreviations per datatype (as opposed to all), we define `ForallXNAME :: constraint -> *` (as in Section 3.7 of the paper) where `NAME` is name of the datatype. However, we do NOT need Trees that Grow in its full generality: as far as I understand, we do not have GADTs or existentials in GHC ASTs. This means we can use the simpler design of Trees that Grow that all extension families had the same arity and kind, then we could factor them all into one type family dispatching on some unique identifier. (we used type-level strings, or promoted datatypes for annotations.) For example, the following in absence of existentials > type family XVar x a > type family XApp x a > type family XAbs x a > data Exp x a > = Var (XVar x a) a > | Abs (XAbs x a) a (Exp x a) > | App (XApp x a) (Exp x a) (Exp x a) is as good as (one of our very first extensible encodings) > type family XDispatch name x a > data Lbl = VarL | AbsL | AppL > data Exp x a > = Var (XDispatch VarL x a) a > | Abs (XDispatch AbsL x a) a (Exp x a) > | App (XDispatch AppL x a) (Exp x a) (Exp x a) We could do the same with promoted datatypes as annotations (instead of type-level strings). The advantage of the simpler encoding is that now, in theory, we can define > ForallXExp (c :: Constraint) x a = forall l. c (XDispatch l x a) Which gives us for example `ForallXExp Outputable x a `. Is this encoding faster, in comparison? Does it help? /Shayan On Fri, Jul 28, 2017 at 10:11 PM, Shayan Najd wrote: > MarLinn, > Thanks for correcting me, and spelling this out. > I did mean what Alan mentioned: "re-parsing a pretty printed parse tree > gives you back a parse tree identical to the original (ignoring SrcSpans)". > As I recall, we had to go a bit further to give 'Something' some more > structure to take into account things like "(ignoring SrcSpans)" (e.g., to > define exact-printers, etc). > Provided I have failed twice to properly recall the invariant, I > refrain from trying to recall the rest tonight :) > > Not diverging from my point above, as far as I understand, an ideal > `Outputable` machinery is going to be a bit different from the traditional > pretty printers. > I believe with a proper design we can even reuse `Outputable` machinery > and provide it as a pretty printer for Haskell terms. > It resembles the scenario in Section 3.7 compared to Section 3.6 of Trees > that Grow [1]. > > Having said all these, we ARE diverging from the original thread, and > Simon's questions. > > How about taking printer-design related discussion to the following wiki > page (and/or a new ghc-dev thread if needed): > https://ghc.haskell.org/trac/ghc/wiki/HaskellSyntaxPrinters > > Cheers, > Shayan > > [1] http://www.jucs.org/jucs_23_1/trees_that_grow/jucs_23_ > 01_0042_0062_najd.pdf > > On Fri, Jul 28, 2017 at 8:43 PM, Alan & Kim Zimmerman > wrote: > >> I agree. 4 is the current GHC invariant. >> >> i.e., re-parsing a pretty printed parse tree gives you back a parse tree >> identical to the original (ignoring SrcSpans) >> >> Alan >> >> On 28 July 2017 at 20:34, MarLinn wrote: >> >>> by >>> >>> (parser . prettyPrint . parser) = id >>> >>> I meant >>> >>> (prettyPrint . parser . prettyPrint) = id >>> >>> for a valid input. >>> >>> Simplifying, (parser ∷ String → something), and (prettyPrint ∷ >>> something → String). >>> >>> Therefore, (parser . prettyPrint . parser ∷ String → something) and (prettyPrint >>> . parser . prettyPrint ∷ something → String). >>> >>> Therefore, both criteria could only apply for (something ~ String). But >>> as pretty printing adds quotation marks, not even that is true. >>> >>> There are four formulations that might be applicable: >>> >>> 1. >>> >>> parser . prettyPrint ≍ id >>> 2. >>> >>> prettyPrint . parser ≍ id -- ∷ String → String, useless here >>> 3. >>> >>> prettyPrint . parser . prettyPrint ≍ prettyPrint >>> 4. >>> >>> parser . prettyPrint . parser ≍ parser >>> 5. Well, you could go beyond to (prettyPrint . parser . prettyPrint >>> . parser ≍ prettyPrint . parser) etc… >>> >>> I don't think 1 (or 2) follow from one of the last two. But 1 does imply >>> them. So it is a stronger criterion than both, and therefore probably not >>> the one to choose. Assuming the parser is internally consistent, 3 just >>> says something about the internal consistency of the pretty printer, while >>> 4 says something about the relationship of the pretty printer to the >>> parser. Thus 4 looks like the best candidate for a criterion. Possibly with >>> 3 as a secondary target. >>> >>> Cheers, >>> MarLinn >>> >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> >>> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Jul 31 09:18:48 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 31 Jul 2017 09:18:48 +0000 Subject: Operating on HsSyn In-Reply-To: References: Message-ID: Am I far off? I don’t think you are far off. All I’m after is the debug-printer use-case: I want to be able to see the contents of the tree, including the PostRn annotations. I don’t care about round-tripping it. Simon From: Shayan Najd [mailto:sh.najd at gmail.com] Sent: 28 July 2017 15:32 To: Simon Peyton Jones Cc: ghc-devs at haskell.org; Alan & Kim Zimmerman ; Jacques Carette Subject: Re: Operating on HsSyn On the contrary, inside GHC I /do/ want to print them. Otherwise how can I see what the renamer has done? Right. So if I understand correctly, with this semantics, `Outputable` is somewhere between pretty printing as often used in program manipulation libraries (like Haskell-Src-Exts (HSE)) which is closer to syntax, and `Show` which is closer to Haskell representation. (There are also "exact printers" (as in HSE) that are even closer to syntax in some sense.) Often, pretty printers generate only grammatically valid terms, not the ones polluted with extra annotations (hence grammatically invalid), e.g., what is the grammatically valid form of `OpApp` printed via `Outputable` that includes the fixity annotation. If I recall correctly, we have briefly studied these in the past summer, we came up with some roundtrip correctness criteria, like the following (bar error handling; assume valid input): (parser . prettyPrint . parser) = id [paging in Jacques] The reason I am trying to flesh out the semantics is the /big/ gains on code reuse later on in the process: one does not need to define a separate pretty printing library for Haskell syntax, and can reuse the well-tested and well-maintained one in GHC. Reformulating part of your concern, based on my understanding (if I may), the questions is: what is the proper design of an "outputer" (debug-printer?) where /annotated/ terms can be pretty-printed including any printable (pretty?showable?) annotations. In particular, we may want to take advantage of extensibility of data types for this. Am I far off? Note: with proper design, an extensible debug-printer can still subsume corresponding pretty-printers. On Fri, Jul 28, 2017 at 2:36 PM, Simon Peyton Jones > wrote: I have been under the impression that we don't even want to print those. On the contrary, inside GHC I /do/ want to print them. Otherwise how can I see what the renamer has done? Simon From: Shayan Najd [mailto:sh.najd at gmail.com] Sent: 28 July 2017 12:20 To: Simon Peyton Jones > Cc: ghc-devs at haskell.org; Alan & Kim Zimmerman > Subject: Re: Operating on HsSyn Before all this, we may need to discuss a bit about the intended semantics of `Outputable`: does it need to print `PostRn`, or `PostTc` fields; or `Out` suffixed constructors? If not, then we only need to write a set of instances for the base growable AST, once and for all. Such instances will be polymorphic on the extension descriptor `p`, and do not need to mention the constraints like `(PostRn p (IdP p)`, since these are just extensions and not part of the base growable AST. Or, am I missing something about the intended semantics of `Outputable`? You write So today we never print these annotations, to avoid bloating the instance contexts, which can be painful. I have been under the impression that we don't even want to print those. Of course, there are scenarios (like `Show` instances) where we do want to write compositional / generic functions that take into account the extensions. Here is my abstract overview of the scenario, that may help the discussion. Consider data types `A`, `B`, and `C` (say, one AST datatype per compiler phase) that are defined as extensions to a base datatype `T`: > A = T XA > B = T XB > C = T XC where `X*`s are extension descriptors. Now, say we want to a define functions `f_A`, `f_B`, and `f_C` over `A`, `B`, and `C`. We have two main alternatives: (a) either we write these (manually or using the deriving mechanism) separately (b) or we write a generic / parametric function `g` over `T`, and reuse that to define `f_*`s Of course, (b) is preferable in theory , but not always possible or preferable in practice. In which case, we can always resort to (a). The more varying are the definitions of `f_A`, `f_B`, and `f_C` the more parametric should `g` get, as this is the case for any generic function. With a correct design, I believe, these are all independent of Trees that Grow story itself: we are now not only trying to reuse data types, and functions agnostic towards extensions (pretty printers in my view of their semantics), but also reuse functions with parametric / varying behaviour with respect to extensions. /Shayan On Fri, Jul 28, 2017 at 10:18 AM, Simon Peyton Jones > wrote: Devs, Shayan is working away on “Trees that grow”… do keep it on your radar: To: ghc-devs Sent: 25 May 2017 23:49 Do take a look at this: • We propose to re-engineer HsSyn itself. This will touch a lot of code. • But it’s very neat, and will bring big long-term advantages • And we can do it a bit at a time The wiki page https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow has the details. It’s entirely an internal change, not a change to GHC’s specification, so it’s independent of the GHC proposals process. But I’d value the opinion of other GHC devs Meanwhile I have a question. When pretty-printing HsSyn we often have a situation like this: data Pass = Parsed | Renamed | Typechecked data HsExpr (p :: Pass) = HsVar (IdP p) | .... type famliy IdP p where IdP Parsed = RdrName IdP Renamed = Name IdP Typechecked = Id instance (Outputable (IdP p)) => Outputable (HsExpr p) where ppr (HsVar v) = ppr v The (ppr v) requires (Outputable (IdP p)), hence the context. Moreover, and more seriously, there are things we just can't pretty-print right now. For example, HsExpr has this data constructor: data HsExpr p = ... | OpApp (LHsExpr p) (LHsExpr p) (PostRn p Fixity) (LHsExpr p) To pretty-print the third argument, we'd need to add instance (Outputable (IdP p), Outputable (PostRn p Fixity)) -- New => Outputable (HsExpr p) where ppr (HsVar v) = ppr v and that gets onerous. So today we never print these annotations, to avoid bloating the instance contexts, which can be painful. It bit me yesterday. We have bitten that bullet for the Data class: look at HsExtension.DataId, which abbreviates the long list of dictionaries: type DataId p = ( Data p , ForallX Data p , Data (NameOrRdrName (IdP p)) , Data (IdP p) , Data (PostRn p (IdP p)) , Data (PostRn p (Located Name)) , Data (PostRn p Bool) , Data (PostRn p Fixity) ,..and nine more... ) Let me note in passing that [wiki:QuantifiedContexts] would make this somewhat shorter type DataId p = ( Data p , ForallX Data p , Data (NameOrRdrName (IdP p)) , Data (IdP p) , forall t. Data t => Data (PostRn p t)) But we still need one item in this list for each type function, and I am worried about how this scales to the [wiki:ImplementingTreesThatGrow] story, when we have a type function for each data constructor -- and there are a lot of data constructors. So I have four questions 1. I think we should probably use a superclass instead of a type synonym class (Data p, ForallX Data p, ....) => DataId p where {} Why? Only one argument to pass, and to pass on to successive calls. I see no downside. 1. Shall we treat Outputable like Data? (I.e. make an abbreviation for a long list of Outputable instances and use it everywhere) 2. I thought of another way to do it (pass a token); see below 1. Are there any other ways? Token passing idea. Perhaps instead of passing lots of functions, we pass a singleton token that encodes the pass, like this: instance (PassC p) => Outputable (HsExpr p) where ppr (HsVar v) = case getPass :: IsPass p of IsParsed -> ppr v IsRenamed -> ppr v IsTypechecked -> ppr v The three ppr's are at different types, of course; that's the point. The infrastructure is something like class PassC p where getPass :: IsPass p data IsPass p where IsParsed :: IsPass Parsed IsRenamed :: IsParsed Renamed IsTypechecked :: IsParsed Typechecked instance PassC Parsed where getPass = IsParsed ...etc... Now we could sweep away all those OutputableX classes, replacing them with dynamic tests on the singletons IsParsed etc. This would have advantages: - Probably faster: there's a dynamic test, but many fewer dictionary arguments and higher-order function dispatch - Only one dictionary to pass; programming is easier. The big downside is that it's not extensible: it works only because we know the three cases. But the "Trees that Grow" story really doesn't scale well to pretty-printing: so maybe we should just give up on that? -------------- next part -------------- An HTML attachment was scrubbed... URL: