From ben at well-typed.com Tue Mar 5 20:53:19 2019 From: ben at well-typed.com (Ben Gamari) Date: Tue, 05 Mar 2019 15:53:19 -0500 Subject: [ANNOUNCE] GHC 8.6.4 is now available Message-ID: <87h8chrqkl.fsf@smart-cactus.org> Hello everyone, The GHC team is very happy to announce the availability of GHC 8.6.4, a bugfix release in the GHC 8.6 series. The source distribution, binary distributions, and documentation for this release are available at https://downloads.haskell.org/~ghc/8.6.4 The 8.6.4 release fixes several regressions present in 8.6.3 including: - A regression resulting in segmentation faults on Windows introduced by the fix for #16071 backported in 8.6.3. This fix has been reverted, meaning that 8.6.4 is once again susceptible to #16071. #16071 will be fixed in GHC 8.8.1. - A bug resulting in incorrect locking on Darwin, potentially resulting in hangs at shutdown (#16150) - A few bugs in the profiled runtime resulting in the potential for memory unsafety has been fixed (#15508). - The `process` and `transformers` libraries shipped now properly reflect released Hackage releases (#16199) - A bug where TH name resolution would break in a plugin context has been fixed (#16104) - Compilers that do not support TemplateHaskell no longer advertise such support in `--supported-languages` (#16331) As a few of these issues are rather serious users are strongly encouraged to upgrade. See Trac [1] for a full list of issues resolved in this release. Note that this release ships with one significant but long-standing bug (#14251): Calls to functions taking both Float# and Double# may result in incorrect code generation when compiled using the LLVM code generator. This is not a new issue, it has existed as long as the LLVM code generator has existed; however, changes in code generation in 8.6 made it more likely that user code using only lifted types will trigger it. Note also that this is the first release cut from our (yet again) revamped continuous integration infrastructure. While we have done a great deal of checking to ensure that the build configuration reflects that of previous releases, do let us know if something looks off. Happy compiling! Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/query?status=closed&milestone=8.6.4&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&order=priority -------------- 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 Mar 6 01:21:09 2019 From: ben at well-typed.com (Ben Gamari) Date: Tue, 05 Mar 2019 20:21:09 -0500 Subject: Final steps in GHC's Trac-to-GitLab migration Message-ID: <8736o0ssqo.fsf@smart-cactus.org> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From omeragacan at gmail.com Wed Mar 6 06:32:44 2019 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Wed, 6 Mar 2019 09:32:44 +0300 Subject: [Haskell-cafe] Final steps in GHC's Trac-to-GitLab migration In-Reply-To: <8736o0ssqo.fsf@smart-cactus.org> References: <8736o0ssqo.fsf@smart-cactus.org> Message-ID: This look great, thanks to everyone involved! Some feedback: - When I click to the "Wiki" link on the left it opens "Home" page and I don't know how to go to the index from there. I think we may want index to be the home page for the wiki? - Redirects don't seem to work: https://gitlab.staging.haskell.org/ghc/ghc/wikis/commentary/rts/heap-objects - Comparing these two pages: https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/HeapObjects?redirectedfrom=Commentary/Rts/HeapObjects https://gitlab.staging.haskell.org/ghc/ghc/wikis/commentary/rts/storage/heap-objects The Gitlab page doesn't have images that Trac page has. Secondly, the "_|_" string used in the Trac page is migrated as italic "|" in Gitlab. Ömer Ben Gamari , 6 Mar 2019 Çar, 04:21 tarihinde şunu yazdı: > > 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. From ben at well-typed.com Wed Mar 6 11:02:45 2019 From: ben at well-typed.com (Ben Gamari) Date: Wed, 06 Mar 2019 06:02:45 -0500 Subject: [Haskell-cafe] Final steps in GHC's Trac-to-GitLab migration In-Reply-To: References: <8736o0ssqo.fsf@smart-cactus.org> Message-ID: On March 6, 2019 1:32:44 AM EST, "Ömer Sinan Ağacan" wrote: >This look great, thanks to everyone involved! > >Some feedback: > >- When I click to the "Wiki" link on the left it opens "Home" page and >I don't >know how to go to the index from there. I think we may want index to be >the > home page for the wiki? > Yes, I do think we at least want to link to the index from the wiki home page. >- Redirects don't seem to work: >https://gitlab.staging.haskell.org/ghc/ghc/wikis/commentary/rts/heap-objects > Yes this needs to be fixed. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From ben at well-typed.com Wed Mar 6 11:21:34 2019 From: ben at well-typed.com (Ben Gamari) Date: Wed, 06 Mar 2019 06:21:34 -0500 Subject: [Haskell-cafe] Final steps in GHC's Trac-to-GitLab migration In-Reply-To: References: <8736o0ssqo.fsf@smart-cactus.org> Message-ID: <91121787-E6C0-45E4-BB7B-B25FBF2B440E@well-typed.com> On March 6, 2019 6:11:49 AM EST, Ara Adkins 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 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. From ben at well-typed.com Sat Mar 9 16:23:10 2019 From: ben at well-typed.com (Ben Gamari) Date: Sat, 09 Mar 2019 11:23:10 -0500 Subject: Trac to GitLab migration underway Message-ID: <87tvgcow4d.fsf@smart-cactus.org> 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/ -------------- 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 Mar 10 21:38:42 2019 From: ben at well-typed.com (Ben Gamari) Date: Sun, 10 Mar 2019 17:38:42 -0400 Subject: Trac to GitLab migration underway In-Reply-To: <87tvgcow4d.fsf@smart-cactus.org> References: <87tvgcow4d.fsf@smart-cactus.org> Message-ID: <87h8caqujm.fsf@smart-cactus.org> Ben Gamari writes: > 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. > Hi everyone, I'm happy to announce that the ticket and issue import processes are now complete and gitlab.haskell.org is back online. There are still a few final steps remaining which I will be carrying out over the next few days: * Put in place redirect logic for Trac ticket and Wiki URLs * Add issue comments showing commit messages, replicating the previous Trac behavior * Migrate the GHC Blog entries * Make the old Trac instance again accessible in read-only mode However, while I do this you should feel free to use gitlab.haskell.org freely. If you notice any issues with the import feel free to open a ticket here [1]. Cheers, - Ben [1] https://gitlab.haskell.org/bgamari/gitlab-migration/issues -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From anthony_clayden at clear.net.nz Wed Mar 13 04:38:14 2019 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Wed, 13 Mar 2019 17:38:14 +1300 Subject: [Haskell-cafe] Final steps in GHC's Trac-to-GitLab migration Message-ID: >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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Sun Mar 17 01:29:12 2019 From: ben at well-typed.com (Ben Gamari) Date: Sat, 16 Mar 2019 21:29:12 -0400 Subject: GitLab updates Message-ID: <87sgvmmgpo.fsf@smart-cactus.org> 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-mapping.json [2] https://gitlab.haskell.org/bgamari/trac-to-remarkup/commit/4104086bca53528b092ad907b6d1f57c5b140587#b39596681b9e4fc60d716cdc07030e8064b03d73_70_72 [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=Wiki -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From anthony_clayden at clear.net.nz Mon Mar 25 05:24:44 2019 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Mon, 25 Mar 2019 18:24:44 +1300 Subject: props for Hugs over System FC Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony_clayden at clear.net.nz Mon Mar 25 05:45:52 2019 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Mon, 25 Mar 2019 18:45:52 +1300 Subject: props for Hugs over System FC In-Reply-To: References: Message-ID: On Mon, Mar 25, 2019 at 6:24 PM Anthony Clayden < anthony_clayden at clear.net.nz> wrote: > ... > Errk. pasted the wrong example. The code that works is class F a b | a -> b instance F Int Bool class D a where { op :: (F a b) => a -> b } instance (TypeCast Bool b') => D Int where { op _ = typeCast True } That dangling `b'` in the constraint is weird. Anyhow: compiles in Hugs, doesn't in GHC. Unless someone here can persuade it? AntC -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony_clayden at clear.net.nz Mon Mar 25 11:49:41 2019 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Tue, 26 Mar 2019 00:49:41 +1300 Subject: Equality constraints (~): type-theory behind them Message-ID: > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Mar 25 12:04:54 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 25 Mar 2019 12:04:54 +0000 Subject: Equality constraints (~): type-theory behind them In-Reply-To: References: Message-ID: 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. To call System FC a straitjacket is to suggest that there is a straightforward alternative that would serve the purpose better – let’s take off the straitjacket! I’m all for that, but then we do need to describe what the new alternative is, at a comparable level of precision. For better or worse, GHC uses FC as a statically-typed intermediate language. Vanishingly few compilers do this; almost all use an untyped intermediate language. With an untyped IR, all you need do is typecheck the source program, and then you are done with typechecking --- provided that all the subsequent transformations and optimisations are sound. But with a statically typed IR, we have to ensure that every transformation produces a program that is itself well-typed; and that in turn pretty much rules out complicated inference algorithms, because they are fragile to transformation. Instead, GHC uses a complicated inference algorithm on the (implicitly typed) source program, but under the straitjacket restriction that the type inference algorithm must also translate the program into an explicitly-typed IR. This is a choice that GHC makes. It’s a choice that I love, and one that makes GHC distinctive. But I accept that it comes with a cost. There may be an IR based on fundeps, or CHRs or something, that has similar properties to FC. It would be a great research goal to work on such a thing. That said, there may be aspects of GHC’s implementation fundeps that are unsatisfactory or argualbly just plain wrong, and which could be fixed and still translate into FC. If anyone would like to work on that, I’d be happy to help explain how the current machinery works. Simon From: Glasgow-haskell-users On Behalf Of Anthony Clayden Sent: 25 March 2019 11:50 To: GHC Users List ; Tom Schrijvers Subject: Re: Equality constraints (~): type-theory behind them > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony_clayden at clear.net.nz Tue Mar 26 03:42:18 2019 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Tue, 26 Mar 2019 16:42:18 +1300 Subject: Equality constraints (~): type-theory behind them In-Reply-To: References: Message-ID: On Tue, Mar 26, 2019 at 1:05 AM Simon Peyton Jones wrote: Whoa, whoa. Your reply is making a number of presuppositions, and putting words in my mouth I did not say. Firstly: I am totally in favour of a typed intermediate language. Then the question is what type-theory do we use within the IR? Well it should be one that fits the surface language. System F-in-general broadly fits functional languages in general. Does System FC in particular fit Haskell specifically? I've seen no demonstration of that; and there are reasons to think it's only an approximate fit. That's why I've talked about "squeezing" and "straitjacket". Quite apart from FunDeps: does FC fit nicely to overlapping instances? I think not. Does FC fit nicely to Type Families? "type families in Haskell provide a powerful, modular means of defining type-level computation. However, their current design implicitly assumes that type families are total, introducing nonsensical types and significantly complicating the metatheory of type families and their extensions." say Eisenberg and Morris 2017. So that's a 'No'. E&M go on to translate Type Families into something that looks more like FunDeps, to my eye. The whole point about FunDeps is they are constrained by typeclasses. So they don't suffer those complications. One of the reasons coders prefer FunDeps is because they can use Overlapping Instances. Then for Schrijvers et al to translate FunDeps to Type Families that a) don't accommodate Overlaps; and b) use a feature (Type Families) that introduce "nonsensical types" and "complicating the metatheory" looks a fortiori like a poor fit. > There may be an IR based on fundeps, or CHRs or something, that has similar properties to FC. Perhaps it's already in FC and it's hiding in plain sight: the 'via CHRs' paper gives its rules in terms of quantified implications (or bi-implications). We now have in GHC the beginnings of Quantified/implication constraints. How are they translated into FC? I've tried looking at the Oliveira et al 2017 paper (section 5), but it's too dense for me. I can see it's in terms of constructing dictionaries, not Type Families. Tom should understand this far better than me: he and George are among the et al. Yet despite all 3 papers I've mentioned dating to 2017, there seems to be no mutual recognition. Tom+George's paper doesn't say they've considered Quantified/implication constraints amongst 'Related Work'. Yet this logic screams at me: class C a b | a -> b, b -> a -- two-way FunDeps instance C Int Bool Mark Jones and the 'via CHRs' paper says that translates to axioms (forall b. C Int b => b ~ Bool, forall a. C a Bool => a ~ Int) That is actual legal code in GHC today, as a constraint. Then all I need is a way to get those axioms into the program's type theory, presuming it can be expressed in FC. Look how succinct that constraint is, compare to introducing two Type Families, one for each direction of the FunDeps; and two TF instances; and two `~` superclass constraints. (I know the Schrijvers et al translates to Associated Types. But those are just sugar for top-level TFs, so they don't avoid the complications E&M talk about.) > I’d be happy to help explain how the current machinery works. Thank you. Is there somewhere a write-up/dummies guide for how GHC translates Quantified/implication constraints into FC? One further thing: > there may be aspects of GHC’s implementation fundeps that are unsatisfactory or argualbly just plain wrong, Yes there are. You can write code in GHC that is just incoherent. There's no hope of translating it into any type theory, and nobody should try. The tenor of your message is that the "just plain wrong" bits are still an open question. Not so: all the explanations are in the 'via CHRs' paper (not to mention flagged with Notes inside GHC source that say "bogus"). There are programs that the 'via CHRs' rules say should be rejected, but that GHC on the face of it accepts. You then find those programs are unusable/can only be used if you're very careful with your function signatures. My rule of thumb is: if Hugs accepts the code, then it will be coherent. If Hugs rejects, the error message corresponds to a rule in 'via CHRs'. No further research needed. AntC 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. > > > > To call System FC a straitjacket is to suggest that there is a > straightforward alternative that would serve the purpose better – let’s > take off the straitjacket! I’m all for that, but then we do need to > describe what the new alternative is, at a comparable level of precision. > > > > For better or worse, GHC uses FC as a statically-typed intermediate > language. Vanishingly few compilers do this; almost all use an untyped > intermediate language. With an untyped IR, all you need do is typecheck > the source program, and then you are done with typechecking --- provided > that all the subsequent transformations and optimisations are sound. > > > > But with a statically typed IR, we have to ensure that every > transformation produces a program that is itself well-typed; and that in > turn pretty much rules out complicated inference algorithms, because they > are fragile to transformation. Instead, GHC uses a complicated inference > algorithm on the (implicitly typed) *source* program, but under the > straitjacket restriction that the type inference algorithm must *also* > translate the program into an *explicitly*-typed IR. > > > > This is a choice that GHC makes. It’s a choice that I love, and one that > makes GHC distinctive. But I accept that it comes with a cost. > > > > There may be an IR based on fundeps, or CHRs or something, that has > similar properties to FC. It would be a great research goal to work on > such a thing. > > > > That said, there may be aspects of GHC’s implementation fundeps that are > unsatisfactory or argualbly just plain wrong, and which could be fixed and > *still* translate into FC. If anyone would like to work on that, I’d be > happy to help explain how the current machinery works. > > > > Simon > > > > *From:* Glasgow-haskell-users *On > Behalf Of *Anthony Clayden > *Sent:* 25 March 2019 11:50 > *To:* GHC Users List ; Tom Schrijvers < > tom.schrijvers at cs.kuleuven.be> > *Subject:* Re: Equality constraints (~): type-theory behind them > > > > > > > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Sun Mar 31 00:56:07 2019 From: ben at well-typed.com (Ben Gamari) Date: Sat, 30 Mar 2019 20:56:07 -0400 Subject: GHC HEAD documentation once again available Message-ID: <87zhpbhnfh.fsf@smart-cactus.org> 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/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: