- Glasgow-haskell-users

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

[ANNOUNCE] GHC 8.6.4 is now available
by Ben Gamari 05 Mar '19

05 Mar '19

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…

1 0

Re: Equality constraints (~): type-theory behind them
by Anthony Clayden 23 Dec '18

23 Dec '18

On Fri, 7 Dec 2018 at 10:57 PM, Adam Gundry wrote: > > Regarding inference, the place that comes to mind is Vytiniotis et al. > OutsideIn(X): > Thanks Adam for the references. Hmm That OutsideIn paper is formidable in so many senses ... I'm not sure I grok your response on my specific q; to adapt your example slightly, without a signature foo2 x@(_: _) = x GHC infers `foo2 :: [a] -> [a]`. That's not general enough. So I give a signature with bare `b` as the return type, using the (~) to improve it: foo2 :: [a] ~ b => [a] -> b ... and GHC infers `foo2 :: [a] -> [a]`. Oh. Is that what I should expect? I'm chiefly concerned about improving bare tyvars under a FunDep. So to take the time-worn example, I want instances morally equivalent to data TTrue = TTrue; data TFalse = TFalse class TEq a b r | a b -> r where tEq :: a -> b -> r instance TEq a a TTrue where tEq _ _ = TTrue instance TEq a b TFalse where tEq _ _ = TFalse The FunDeps via CHRs 2006 paper tells me that first instance is supposed to be as if instance (r ~ TTrue) => TEq a a r where ... but it isn't tEq 'a' 'a' :: TFalse -- returns TFalse, using the first pair of instances tEq 'a' 'a' :: TFalse -- rejected, using the (~) instance: 'Couldn't match type TFalse with TTrue ...' The 'happily' returning the 'wrong' answer in the first case has caused consternation amongst beginners, and a few Trac tickets. So what magic is happening with (~) that it can eagerly improve `foo2` but semi-lazily hold back for `tEq`? Of course I lied about the first-given two instances for TEq: instances are not consistent with Functional Dependency. So I need to resort to overlaps and a (~) and exploit GHC's bogus consistency check: instance {-# OVERLAPPABLE #-} (r ~ TFalse) => TEq a b r where ... > ... like automatically inferring where `typeCast` needs to be placed Yes the non-automatic `TypeCast` version instance (TypeCast TTrue r) => TEq a a r where tEq _ _ = TTrue -- rejected 'Couldn't match expected type 'r' with actual type 'TTrue' ...' tEq _ _ = typeCast TTrue -- accepted Even though `typeCast` is really `id` (after it's jumped through the devious indirection hoops I talked about). So what I'm trying to understand is not just "where" to place `typeCast` but also "when" in inference it unmasks the unification. AntC > About your specific question, if a wanted constraint `a ~ b` can be > solved by unifying `a` with `b`, then GHC is free to do so (in a sense, > either parameter of (~) can be improved from the other). The real > difference with `TypeCast` arises when local equality assumptions (given > constraints) are involved, because then there may be wanted constraints > that cannot be solved by unification but can be solved by exploiting the > local assumptions. > > For example, consider this function: > > foo :: forall a b . a ~ b => [a] -> [b] > foo x = x > > When checking the RHS of `foo`, a wanted constraint `[a] ~ [b]` arises > (because `x` has type `[a]` and is used in a place where `[b]` is > expected). Since `a` and `b` are universally quantified variables, this > cannot be solved by unification. However, the local assumption (given > constraint) `a ~ b` can be used to solve this wanted. > > This is rather like automatically inferring where `typeCast` needs to be > placed (indeed, at the Core level there is a construct for casting by an > equality proof, which plays much the same role). > > Hope this helps, > > Adam > > > On 06/12/2018 12:01, Anthony Clayden wrote: > > The (~) constraint syntax is enabled by either `GADTs` or `TypeFamilies` > > language extension. > > > > GADTs/Assoc Data Types/Assoc Type Synonyms/Type Families arrived in a > > series of papers 2005 to 2008, and IIRC the development wasn't finished > > in full in GHC until after that. (Superclass constraints took up to > > about 2010.) > > > > Suppose I wanted just the (~) parts of those implementations. Which > > would be the best place to look? (The Users Guide doesn't give a > > reference.) ICFP 2008 'Type Checking with Open Type Functions' shows > > uses of (~) in user-written code, but doesn't explain it or motivate it > > as a separate feature. > > > > My specific question is: long before (~), it was possible to write a > > TypeCast class, with bidirectional FunDeps to improve each type > > parameter from the other. But for the compiler to see the type > > improvement at term level, typically you also need a typeCast method and > > to explicitly wrap a term in it. If you just wrote a term of type `a` in > > a place where `b` was wanted, the compiler would either fail to see your > > `TypeCast a b`, or unify the two too eagerly, then infer an overall type > > that wasn't general enough. > > > > (For that reason, the instance for TypeCast goes through some > > devious/indirect other classes/instances or exploits separate > > compilation, to hide what's going on from the compiler's enthusiasm.) > > > > But (~) does some sort of magic: it's a kinda typeclass but without a > > method. How does it mesh with type improvement in the goldilocks zone: > > neither too eager nor too lazy? > > > > > > AntC > > >

4 7

[ANNOUNCE] GHC 8.6.3 is now available
by Ben Gamari 17 Dec '18

17 Dec '18

Hello everyone, The GHC team is very happy to announce the availability of GHC 8.6.3, 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.3 The 8.6 release fixes several regressions present in 8.6.2 including: - A code generation bug resulting in segmentations faults in some programs (#15892) - Darwin binary distributions are now correctly built against an in-tree GMP (#15404) - Three bugs leading to linker failures on Windows (#15105, #15894, #15934) - A bug leading to programs with deep stacks crashing when run with retainer profiling enabled (#14758) - A bug resulting in potential heap corruption during stable name allocation (#15906) - Plugins are now loaded during GHCi sessions (#15633) 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. Happy compiling! Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/query?status=closed&milestone=8.6.3&col=id…

2 1

Does anyone have much experience generating Haskell from Coq?
by Tim Watson 10 Dec '18

10 Dec '18

So far I've been reading https://www.cs.purdue.edu/homes/bendy/Fiat/FiatByteString.pdf. I'm interested in the ideas presented in https://github.com/DistributedComponents/verdi-runtime, which is OCaml based. My goal is to provide building blocks for verifying and testing Cloud Haskell programs. I've been looking at existing frameworks (such as quickcheck-state-machine/-distributed and hedgehog) for model based testing, and ways of injecting an application layer scheduler for detecting race conditions. The final bit of the puzzle is being able to apply formal methods to verify concurrent/distributed algorithms, and generate some (if not all) of the required implementation code. Any pointers to research or prior art would be greatly appreciated. Cheers, Tim Watson

2 2

Guidelines for respectful communication
by Simon Peyton Jones 08 Dec '18

08 Dec '18

Friends As many of you will know, I have been concerned for several years about the standards of discourse in the Haskell community. I think things have improved since the period that drove me to write my Respect email<https://mail.haskell.org/pipermail/haskell/2016-September/024995.html>, but it's far from secure. We discussed this at a meeting of the GHC Steering Committee<https://github.com/ghc-proposals/ghc-proposals> at ICFP in September, and many of us have had related discussions since. Arising out of that conversation, the GHC Steering Committee has decided to adopt these Guidelines for respectful communication<https://github.com/ghc-proposals/ghc-proposals/blob/master/GRC.rst> We are not trying to impose these guidelines on members of the Haskell community generally. Rather, we are adopting them for ourselves, as a signal that we seek high standards of discourse in the Haskell community, and are willing to publicly hold ourselves to that standard, in the hope that others may choose to follow suit. We are calling them "guidelines for respectful communication" rather than a "code of conduct", because we want to encourage good communication, rather than focus on bad behaviour. Richard Stallman's recent post<https://lwn.net/Articles/769167/> about the new GNU Kind Communication Guidelines<https://gnu.org/philosophy/kind-communication.html> expresses the same idea. Meanwhile, the Stack community is taking a similar approach<https://www.snoyman.com/blog/2018/11/proposal-stack-coc>. Our guidelines are not set in stone; you can comment here<https://github.com/ghc-proposals/ghc-proposals/commit/373044b5a78519071b9a2…>. Perhaps they can evolve so that other Haskell committees (or even individuals) feel able to adopt them. The Haskell community is such a rich collection of intelligent, passionate, and committed people. Thank you -- I love you all! Simon

2 1

Equality constraints (~): type-theory behind them
by Anthony Clayden 07 Dec '18

07 Dec '18

The (~) constraint syntax is enabled by either `GADTs` or `TypeFamilies` language extension. GADTs/Assoc Data Types/Assoc Type Synonyms/Type Families arrived in a series of papers 2005 to 2008, and IIRC the development wasn't finished in full in GHC until after that. (Superclass constraints took up to about 2010.) Suppose I wanted just the (~) parts of those implementations. Which would be the best place to look? (The Users Guide doesn't give a reference.) ICFP 2008 'Type Checking with Open Type Functions' shows uses of (~) in user-written code, but doesn't explain it or motivate it as a separate feature. My specific question is: long before (~), it was possible to write a TypeCast class, with bidirectional FunDeps to improve each type parameter from the other. But for the compiler to see the type improvement at term level, typically you also need a typeCast method and to explicitly wrap a term in it. If you just wrote a term of type `a` in a place where `b` was wanted, the compiler would either fail to see your `TypeCast a b`, or unify the two too eagerly, then infer an overall type that wasn't general enough. (For that reason, the instance for TypeCast goes through some devious/indirect other classes/instances or exploits separate compilation, to hide what's going on from the compiler's enthusiasm.) But (~) does some sort of magic: it's a kinda typeclass but without a method. How does it mesh with type improvement in the goldilocks zone: neither too eager nor too lazy? AntC

2 1