- Glasgow-haskell-users

[ANNOUNCE] GHC 8.8.1-alpha1 is now available
by Ben Gamari 26 Apr '19

26 Apr '19

Hello everyone, The GHC team is pleased to announce the first alpha release of GHC 8.8.1. The source distribution, binary distributions, and documentation are available at https://downloads.haskell.org/~ghc/8.8.1-alpha1 A draft of the release notes is also available [1]. This release is the culmination of over 3000 commits by over one hundred contributors and has several new features and numerous bug fixes relative to GHC 8.6: * Profiling now works correctly on 64-bit Windows (although still may be problematic on 32-bit Windows due to platform limitations; see #15934) * A new code layout algorithm for amd64's native code generator * The introduction of a late lambda-lifting pass which may reduce allocations significantly for some programs. * Further work on Trees That Grow, enabling improved code re-use of the Haskell AST in tooling * More locations where users can write `forall` (GHC Proposal #0007) * Further work on the Hadrian build system This release starts the pre-release cycle for GHC 8.8. This cycle is starting quite a bit later than expected due recent work on GHC's CI and release infrastructure. See the GHC Blog [2] for more on this. As always, if anything looks amiss do let us know. Happy compiling! Cheers, - Ben [1] https://downloads.haskell.org/ghc/8.8.1-alpha1/docs/html/users_guide/8.8.1-… [2] https://www.haskell.org/ghc/blog/20190405-ghc-8.8-status.html

2 1

[ANNOUNCE] GHC 8.6.5-rc1 is now available
by Ben Gamari 08 Apr '19

08 Apr '19

Hello everyone, The GHC team is proud to announce the first release candidate of 8.6.5. The source distribution, binary distributions, and documentation are available at https://downloads.haskell.org/~ghc/8.6.5-rc1 This release fixes a handful of issues with 8.6.4: - Binary distributions once again ship with Haddock documentation including syntax highlighted source of core libraries (#16445) - A build system issue where use of GCC with `-flto` broke `configure` was fixed (#16440) - An bug affecting Windows platforms wherein XMM register values could be mangled when entering STG has been fixed (#16514) - Several Windows packaging issues resulting from the recent CI rework. (#16408, #16398, #16516) Since this is a relatively small bugfix release we are bypassing the alpha releases and moving right to the release candidate stage. If all goes well the final release will be cut next week. As always, if anything looks amiss do let us know. Happy testing! Cheers, - Ben

1 0

GHC HEAD documentation once again available
by Ben Gamari 31 Mar '19

31 Mar '19

TL;DR. A snapshot of GHC's documentation from the master branch can always be found at [2]. Hi everyone, Quite a while ago I made it a habit of periodically pushing documentation snapshots from GHC's master branch to downloads.haskell.org [1]. Unfortunately, despite some attempts at automating this process, this frequently grew out-of-date. I am happy to report that documentation snapshots are now generated as a product of GHC's CI process and made available here [2]. The old downloads.haskell.org URL redirects to [2] and consequently should now always be up-to-date. Let me know if you notice anything amiss. Cheers, - Ben [1] https://downloads.haskell.org/ghc/master/ [2] https://ghc.gitlab.haskell.org/ghc/doc/

1 0

Re: Equality constraints (~): type-theory behind them
by Anthony Clayden 26 Mar '19

26 Mar '19

> On Mon, Dec 10, 2018 at 8:36:42 AM Tom Schrijvers wrote: > Maybe our Haskell'17 paper about Elaboration on Functional Dependencies sheds some more light on your problem: Thanks Tom, I've also been working through the 2011 expanded version of 'System F with Type Equality Coercions' that Adam suggested. I'm finding your 2017 paper's proposals not up to the job, because it doesn't consider FunDeps for Overlapping Instances; and unnecessary because the examples it's addressing can be fixed purely using FunDeps, with their semantics per the 2006 'via CHRs' paper. The chief problems with using FunDeps in GHC code is GHC doesn't follow that semantics; neither does it follow any other well-principled/documented semantics.You can get it to accept a bunch of instances then find that taken together they're not consistent and confluent, in the sense of the 'via CHRs' paper. Specifically, re the 2017's paper Challenge 1: Enforcing (essentially Trac #10675). That set of instances in the example is not valid by the 'via CHRs' rules, and should be rejected. Hugs indeed rejects that code. GHC accepts it and #10675 shows what sort of incoherence can result. I'm not seeing we need to translate to Type Families/System FC to explain it. Re Challenge 2: Elaborating (which is Trac #9627 that gives the main example for the paper). We can fix that code with an extra `~` constraint: class C a b | a -> b instance C Int Bool f :: (C Int b, b ~ Bool) => b -> Bool f x = x (Or in Hugs with a `TypeCast` instead of the `~`.) Is that extra constraint onerous? The signature already has `Bool` hard-coded as the return type, so I don't see it's any more onerous. Or put that signature as f :: (C Int b) => b -> b Which also has the effect `b` must be `Bool`. I'd far rather see GHC's implementation of FunDeps made more coherent (and learning from Hugs) than squeezing it into the straitjacket of System FC and thereby lose expressivity. AntC

2 2

props for Hugs over System FC
by Anthony Clayden 25 Mar '19

25 Mar '19

heh heh. I've got to record this for posterity. I've never known an example before. Some code that compiles in Hugs and works fine; but GHC (8.6.4) can't typecheck so rejects. It's an example in the 2011 'System F with Type Equality Coercions', section 2.3 discussing FunDeps; and used to justify the extra power of type inference in Type Families as opposed to FunDeps. Full details discussed here: https://gitlab.haskell.org/ghc/ghc/issues/16430#note_189393 class F a b | a -> b instance F Int Bool class D a where { op :: F a b => a -> b } instance D Int where { op _ = True } True that doesn't compile as given. Hugs says: 'Inferred type is not general enough'. GHC says 'Couldn't match expected type `b' with actual type `Bool''/ '`b' is a rigid type variable'. (So essentially the same failure of typechecking.) With a little help for the type inference, this compiles in Hugs. class C a b | a -> b instance C Int Bool f :: (C Int b, TypeCast b Bool) => b -> Bool f x = typeCast x With `TypeCast` defined as for HList. But GHC still rejects it; and rejects a version with a `(~)` constraint instead of the `TypeCast`. AntC

1 1

GitLab updates
by Ben Gamari 17 Mar '19

17 Mar '19

Hi everyone, I want to share a few developments on the GitLab migration front: * URLs pointing to tickets or the Wiki which were previously served by Trac (https://ghc.haskell.org/) now redirect to their corresponding GitLab URL. Wiki page names are redirected via this mapping [1]. If you find any cases were this doesn't work as you would expect then please do let me know or open a ticket [4]. If you do want to view Trac you may do so (for the time being) at https://trac.haskell.org/. In the coming days I will be taking a final static archival snapshot of our Trac instance and in the next few weeks we will likely shut it down. * This afternoon I imported [2] a few dozen keywords from Trac that were omitted from the initial import. At this point the ghc/ghc project has nearly 100 labels. It's unclear how usable this will be without either paring down the label space or imposing some sort of order (e.g. adding categorical prefixes to label names) but time will tell. * Our GitLab installation has been upgraded to GitLab 11.8. The changes are relatively minor but I am sure you will spot them. * The source for GHC's homepage (https://www.haskell.org/ghc) is now hosted in the ghc/homepage project [3]. If you find anything wrong with the website feel free to submit a merge request. As always, if you find anything amiss don't hesitate to ping me or open a ticket [4]. Note that the Wiki is still in need of quite a bit of cleanup [5]. If you have some time and want to help out either pick up a ticket or just start browsing and clean-up the first page you find. Many hands makes for light work. However, if you end up renaming any Wiki pages please do open a merge request updating `wiki-mapping.json` [1]. Thank you for your patience while we push through the remaining parts of the migration. Cheers, - Ben [1] https://gitlab.haskell.org/bgamari/gitlab-migration/blob/master/wiki-mappin… [2] https://gitlab.haskell.org/bgamari/trac-to-remarkup/commit/4104086bca53528b… [3] https://gitlab.haskell.org/ghc/homepage [4] https://gitlab.haskell.org/bgamari/gitlab-migration/issues [5] https://gitlab.haskell.org/bgamari/gitlab-migration/issues?label_name%5B%5D…

1 0

Re: [Haskell-cafe] Final steps in GHC's Trac-to-GitLab migration
by Anthony Clayden 13 Mar '19

13 Mar '19

>On March 6, 2019 11:21:34 UTC, Ben Gamari wrote: >>On March 6, 2019 6:11:49 AM EST, Ara Adkins wrote:>>*One question: what is happening with the trac tickets mailing list? I *>>*imagine it’ll be going away, but for those of us that use it to keep *>>*track of things is there a recommended alternative? *>> Yes I look at that as a way to keep a finger lightly on the pulse - chiefly for what users think ghc should be doing. >The ghc-commits list will continue to work. But that's only fixes, not explanations. >The ghc-tickets list is a good question. I suspect that under gitlab there will be less need for this list but we may still want to continue maintaining it regardless for continuity's sake. Thoughts? The gitlab issues list can be sorted by latest update, which should be roughly equiv. But it's showing weird stuff at the moment. (Like decades-old closed tickets with activity 1 day ago.) I guess that's a 'feature' of the migration(?) AntC

1 0

Trac to GitLab migration underway
by Ben Gamari 10 Mar '19

10 Mar '19

Hello everyone, I have started the process of migrating GHC's Trac content to GitLab. GitLab (gitlab.haskell.org) and Trac (ghc.haskell.org) will be down until this process has finished. I will post updates as necessary. However, if you do need to refer to a ticket, you are welcome to use the staging server [1], which has a reasonably up-to-date (read-only) snapshot of our Trac tickets. However, do note that unfortunately authentication via GitHub will not work on this site. Cheers, - Ben [1] https://gitlab.staging.haskell.org/

1 1

Re: [Haskell-cafe] Final steps in GHC's Trac-to-GitLab migration
by Ben Gamari 06 Mar '19

06 Mar '19

On March 6, 2019 6:11:49 AM EST, Ara Adkins <me(a)ara.io> wrote: >Super excited for this! Thank you to everyone whose put in so much hard >work to get it done! > >One question: what is happening with the trac tickets mailing list? I >imagine it’ll be going away, but for those of us that use it to keep >track of things is there a recommended alternative? > The ghc-commits list will continue to work. The ghc-tickets list is a good question. I suspect that under gitlab there will be less need for this list but we may still want to continue maintaining it regardless for continuity's sake. Thoughts? Cheers, - Ben >Best, >_ara > >> On 6 Mar 2019, at 01:21, Ben Gamari <ben(a)well-typed.com> wrote: >> >> Hi everyone, >> >> Over the past few weeks we have been hard at work sorting out the >> last batch of issues in GHC's Trac-to-GitLab import [1]. At this >point I >> believe we have sorted out the issues which are necessary to perform >the >> final migration: >> >> * We are missing only two tickets (#1436 and #2074 which will require >a >> bit of manual intervention to import due to extremely large >> description lengths) >> >> * A variety of markup issues have been resolved >> >> * More metadata is now preserved via labels. We may choose to >> reorganize or eliminate some of these labels in time but it's >easier >> to remove metadata after import than it is to reintroduce it. The >> logic which maps Trac metadata to GitLab labels can be found here >[2] >> >> * We now generate a Wiki table of contents [3] which is significantly >> more readable than GitLab's default page list. This will be updated >> by a cron job until underlying GitLab pages list becomes more >> readable. >> >> * We now generate redirects for Trac ticket and Wiki links (although >> this isn't visible in the staging instance) >> >> * Milestones are now properly closed when closed in Trac >> >> * Mapping between Trac and GitLab usernames is now a bit more robust >> >> As in previous test imports, we would appreciate it if you could have >a >> look over the import and let us know of any problems your encounter. >> >> If no serious issues are identified with the staging site we plan to >> proceed with the migration this coming weekend. The current migration >> plan is to perform the final import on gitlab.haskell.org on >Saturday, 9 >> March 2019. >> >> This will involve both gitlab.haskell.org and ghc.haskell.org being >down >> for likely the entirety of the day Saturday and likely some of Sunday >> (EST time zone). Read-only access will be available to >> gitlab.staging.haskell.org for ticket lookup while the import is >> underway. >> >> After the import we will wait at least a week or so before we begin >the >> process of decommissioning Trac, which will be kept in read-only mode >> for the duration. >> >> Do let me know if the 9 March timing is problematic. >> >> Cheers, >> >> - Ben >> >> >> [1] https://gitlab.staging.haskell.org/ghc/ghc >> [2] >https://github.com/bgamari/trac-to-remarkup/blob/master/TicketImport.hs#L227 >> [3] https://gitlab.staging.haskell.org/ghc/ghc/wikis/index >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.

1 0

Final steps in GHC's Trac-to-GitLab migration
by Ben Gamari 06 Mar '19

06 Mar '19

Hi everyone, Over the past few weeks we have been hard at work sorting out the last batch of issues in GHC's Trac-to-GitLab import [1]. At this point I believe we have sorted out the issues which are necessary to perform the final migration: * We are missing only two tickets (#1436 and #2074 which will require a bit of manual intervention to import due to extremely large description lengths) * A variety of markup issues have been resolved * More metadata is now preserved via labels. We may choose to reorganize or eliminate some of these labels in time but it's easier to remove metadata after import than it is to reintroduce it. The logic which maps Trac metadata to GitLab labels can be found here [2] * We now generate a Wiki table of contents [3] which is significantly more readable than GitLab's default page list. This will be updated by a cron job until underlying GitLab pages list becomes more readable. * We now generate redirects for Trac ticket and Wiki links (although this isn't visible in the staging instance) * Milestones are now properly closed when closed in Trac * Mapping between Trac and GitLab usernames is now a bit more robust As in previous test imports, we would appreciate it if you could have a look over the import and let us know of any problems your encounter. If no serious issues are identified with the staging site we plan to proceed with the migration this coming weekend. The current migration plan is to perform the final import on gitlab.haskell.org on Saturday, 9 March 2019. This will involve both gitlab.haskell.org and ghc.haskell.org being down for likely the entirety of the day Saturday and likely some of Sunday (EST time zone). Read-only access will be available to gitlab.staging.haskell.org for ticket lookup while the import is underway. After the import we will wait at least a week or so before we begin the process of decommissioning Trac, which will be kept in read-only mode for the duration. Do let me know if the 9 March timing is problematic. Cheers, - Ben [1] https://gitlab.staging.haskell.org/ghc/ghc [2] https://github.com/bgamari/trac-to-remarkup/blob/master/TicketImport.hs#L227 [3] https://gitlab.staging.haskell.org/ghc/ghc/wikis/index

2 2