From simonpj at microsoft.com Thu Dec 6 10:35:11 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 6 Dec 2018 10:35:11 +0000 Subject: Guidelines for respectful communication Message-ID: 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, but it's far from secure. We discussed this at a meeting of the GHC Steering Committee 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 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 about the new GNU Kind Communication Guidelines expresses the same idea. Meanwhile, the Stack community is taking a similar approach. Our guidelines are not set in stone; you can comment here. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 19640 bytes Desc: not available URL: From anthony_clayden at clear.net.nz Thu Dec 6 12:01:58 2018 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Fri, 7 Dec 2018 01:01:58 +1300 Subject: Equality constraints (~): type-theory behind them Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at well-typed.com Fri Dec 7 09:21:42 2018 From: adam at well-typed.com (Adam Gundry) Date: Fri, 7 Dec 2018 09:21:42 +0000 Subject: Equality constraints (~): type-theory behind them In-Reply-To: References: Message-ID: Hi AntC [with apologies for the duplicate email], Regarding inference, the place that comes to mind is Vytiniotis et al. OutsideIn(X): Modular type inference with local assumptions. JFP 2011. . On the underlying core language, there are various papers starting with Sulzmann et al. System F with type equality coercions. TLDI 2007. 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 -- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ From ben at well-typed.com Sat Dec 8 01:43:37 2018 From: ben at well-typed.com (Ben Gamari) Date: Fri, 07 Dec 2018 20:43:37 -0500 Subject: [ANNOUNCE] GHC 8.6.3 is now available Message-ID: <878t10vlmk.fsf@smart-cactus.org> 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&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: 483 bytes Desc: not available URL: From anthony_clayden at clear.net.nz Sat Dec 8 05:41:54 2018 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Sat, 8 Dec 2018 18:41:54 +1300 Subject: Equality constraints (~): type-theory behind them In-Reply-To: <7186c57d-3a79-91f8-0bcd-a9da3a8bd85a@gundry.co.uk> References: <7186c57d-3a79-91f8-0bcd-a9da3a8bd85a@gundry.co.uk> Message-ID: 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 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From watson.timothy at gmail.com Sat Dec 8 12:05:33 2018 From: watson.timothy at gmail.com (Tim Watson) Date: Sat, 8 Dec 2018 12:05:33 +0000 Subject: Does anyone have much experience generating Haskell from Coq? Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From watson.timothy at gmail.com Sat Dec 8 18:08:22 2018 From: watson.timothy at gmail.com (Tim Watson) Date: Sat, 8 Dec 2018 18:08:22 +0000 Subject: Guidelines for respectful communication In-Reply-To: References: Message-ID: I think this is brilliant. Will have a good read of them, and do my best to adopt them for my own projects and any interactions I have within the community. Thank you Simon! PS: we love you too! :D On Thu, 6 Dec 2018 at 10:35, Simon Peyton Jones via Glasgow-haskell-users < glasgow-haskell-users at haskell.org> wrote: > 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 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/373044b5a78519071b9a24b3681cfd1af06e57e0>. > 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 > > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom.schrijvers at cs.kuleuven.be Mon Dec 10 08:36:07 2018 From: tom.schrijvers at cs.kuleuven.be (Tom Schrijvers) Date: Mon, 10 Dec 2018 09:36:07 +0100 Subject: Equality constraints (~): type-theory behind them In-Reply-To: References: <7186c57d-3a79-91f8-0bcd-a9da3a8bd85a@gundry.co.uk> Message-ID: Hi Anthony, Maybe our Haskell'17 paper about Elaboration on Functional Dependencies sheds some more light on your problem: https://people.cs.kuleuven.be/~tom.schrijvers/Research/papers/haskell2017a.pdf Cheers, Tom On Sat, Dec 8, 2018 at 6:42 AM Anthony Clayden wrote: > 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 >> >> >> _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > -- prof. dr. ir. Tom Schrijvers Research Professor KU Leuven Department of Computer Science Celestijnenlaan 200A 3001 Leuven Belgium Phone: +32 16 327 830 http://people.cs.kuleuven.be/~tom.schrijvers/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From gershomb at gmail.com Mon Dec 10 09:30:14 2018 From: gershomb at gmail.com (Gershom B) Date: Mon, 10 Dec 2018 04:30:14 -0500 Subject: [cloud-haskell-developers] Does anyone have much experience generating Haskell from Coq? In-Reply-To: References: Message-ID: The other approach, which has been quite successful, by the penn team, is using hs-to-coq to extract coq from haskell and _then_ verify: https://github.com/antalsz/hs-to-coq -g On Sat, Dec 8, 2018 at 7:05 AM Tim Watson wrote: > > 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 > > -- > You received this message because you are subscribed to the Google Groups "cloud-haskell-developers" group. > To unsubscribe from this group and stop receiving emails from it, send an email to cloud-haskell-developers+unsubscribe at googlegroups.com. > To post to this group, send email to cloud-haskell-developers at googlegroups.com. > Visit this group at https://groups.google.com/group/cloud-haskell-developers. > For more options, visit https://groups.google.com/d/optout. From anthony_clayden at clear.net.nz Mon Dec 10 10:12:58 2018 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Mon, 10 Dec 2018 23:12:58 +1300 Subject: Equality constraints (~): type-theory behind them In-Reply-To: References: <7186c57d-3a79-91f8-0bcd-a9da3a8bd85a@gundry.co.uk> Message-ID: On Mon, 10 Dec 2018 at 9:36 PM, Tom Schrijvers wrote: > Maybe our Haskell'17 paper about Elaboration on Functional Dependencies > sheds some more light on your problem: > > https://people.cs.kuleuven.be/~tom.schrijvers/Research/papers/haskell2017a.pdf > > Thank you Tom, looks interesting and very applicable. It'll be a few days before I can take a proper look. I see you compare GHC vs Hugs: good, they differ significantly in the details of implementation. I found Hugs well-principled, whereas GHC is far too sloppy in what instances it accepts (but then you find they're unusable). Maybe I scanned your paper too quickly, but it looks like you insist on non-overlapping instances (or that if instances overlap, they are 'confluent', in the terminology of the 2005~2008 work; or 'coincident' in Richard E's work). And the 2006 CHRs paper takes the same decision. That's a big disappointment: I think the combo of Overlap+FunDeps makes sense (you need to use (~) constraints -- hence this thread), and there's plenty of code using the combo -- including the HList 2004 paper (with `TypeCast`). You can make that combo work with GHC, as did HList. But it's hazardous because of GHC's sloppiness/bogusness. You can't make that combo work with Hugs as released; but because it's a better principled platform, a limited-scope tweak to the compiler makes it work beautifully. Documented here: https://ghc.haskell.org/trac/ghc/ticket/15632#comment:2 AntC > On Sat, Dec 8, 2018 at 6:42 AM Anthony Clayden < > anthony_clayden at clear.net.nz> wrote: > >> 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 >>> >>> >>> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > > >> > > -- > prof. dr. ir. Tom Schrijvers > > Research Professor > KU Leuven > Department of Computer Science > > Celestijnenlaan 200A > > 3001 Leuven > > Belgium > > Phone: +32 16 327 830 > http://people.cs.kuleuven.be/~tom.schrijvers/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From watson.timothy at gmail.com Mon Dec 10 10:38:39 2018 From: watson.timothy at gmail.com (Tim Watson) Date: Mon, 10 Dec 2018 10:38:39 +0000 Subject: [cloud-haskell-developers] Does anyone have much experience generating Haskell from Coq? In-Reply-To: References: Message-ID: On Mon, 10 Dec 2018, 09:30 Gershom B The other approach, which has been quite successful, by the penn team, > is using hs-to-coq to extract coq from haskell and _then_ verify: > https://github.com/antalsz/hs-to-coq Thank you! Someone else proposed that off list yesterday too. If we get our layering right, that could definitely be a viable alternative! I will do some more research. I generally think that https://deepspec.org/ is an awesome idea. :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From juhpetersen at gmail.com Mon Dec 17 04:42:17 2018 From: juhpetersen at gmail.com (Jens Petersen) Date: Mon, 17 Dec 2018 13:42:17 +0900 Subject: [ANNOUNCE] GHC 8.6.3 is now available In-Reply-To: <878t10vlmk.fsf@smart-cactus.org> References: <878t10vlmk.fsf@smart-cactus.org> Message-ID: On Sat, 8 Dec 2018 at 10:44, Ben Gamari wrote: > The GHC team is very happy to announce the availability of GHC 8.6.3, a > bugfix release in the GHC 8.6 series. Thanks, I have built 8.6.3 in the Fedora ghc:8.6 module for Fedora 28, 29, and also Rawhide. Currently it is still in the updates-testing-modular repo (8.6.2 is in updates-modular). If you are using Fedora and you can switch to ghc:8.6 and install 8.6.3 like this: $ sudo dnf module enable ghc:8.6 $ sudo dnf --enablerepo=updates-testing-modular install ghc Thanks, Jens From anthony_clayden at clear.net.nz Sat Dec 22 11:08:13 2018 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Sat, 22 Dec 2018 19:08:13 +0800 Subject: Equality constraints (~): type-theory behind them In-Reply-To: References: <7186c57d-3a79-91f8-0bcd-a9da3a8bd85a@gundry.co.uk> Message-ID: On Mon, 10 Dec 2018 at 6:12 PM, Anthony Clayden < anthony_clayden at clear.net.nz> wrote: > On Mon, 10 Dec 2018 at 9:36 PM, Tom Schrijvers wrote: > >> Maybe our Haskell'17 paper about Elaboration on Functional Dependencies >> sheds some more light on your problem: >> >> https://people.cs.kuleuven.be/~tom.schrijvers/Research/papers/haskell2017a.pdf >> >> > Thank you Tom, looks interesting and very applicable. It'll be a few days > before I can take a proper look. > So the paper's main motivation is wrt Trac #9670. I've added some comments there, including a link to your paper. In particular, both GHC and Hugs will infer the 'right' type -- i.e. as improved from the FunDep. But neither allows you to use that improvement to write the desired function `f`. It's a phasing of inference thing(?) I feel I'm not getting much light shed. No amount of adding `(~)` in GHC nor `TypeCast`+`typeCast` method in Hugs will get #9670 function `f` to compile. So my 'specific example' earlier in this thread shows `(~)` is moderately eager/more eager than FunDeps alone, but not eager enough for #9670. IOW from Adam's comment about "inferring where `typeCast` needs to be placed", it seems there's no such place. Perhaps because class `C` has no methods(?) Yes, as per your+Georgios' paper, replacing the FunDep with an Assoc Type and superclass `(~)` constraint is eager enough. That's not telling me why the FunDep+`(~)` constraint on the instances or function signatures isn't so eager. >From the #9670 comment by spj: it's historically to do with an inability to represent evidence under System FC. It seems GHC is taking absence of evidence as evidence of absence, even though it's able to infer the 'right' type. AntC On Fri, 7 Dec 2018 at 10:57 PM, Adam Gundry wrote: >>> >>>> ... >>> >>> 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). >>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ollie at ocharles.org.uk Sat Dec 22 12:00:47 2018 From: ollie at ocharles.org.uk (Oliver Charles) Date: Sat, 22 Dec 2018 12:00:47 +0000 Subject: Equality constraints (~): type-theory behind them In-Reply-To: References: <7186c57d-3a79-91f8-0bcd-a9da3a8bd85a@gundry.co.uk> Message-ID: On Sat, Dec 22, 2018 at 11:08 AM Anthony Clayden wrote: > So the paper's main motivation is wrt Trac #9670. Are you sure you mean #9670? https://ghc.haskell.org/trac/ghc/ticket/9670 is "Make Data.List.tails a good producer for list fusion" and has nothing to do with functional dependencies. From anthony_clayden at clear.net.nz Sat Dec 22 14:26:40 2018 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Sat, 22 Dec 2018 22:26:40 +0800 Subject: Equality constraints (~): type-theory behind them In-Reply-To: References: <7186c57d-3a79-91f8-0bcd-a9da3a8bd85a@gundry.co.uk> Message-ID: On Sat, 22 Dec 2018 at 8:01 PM, Oliver Charles wrote: On Sat, Dec 22, 2018 at 11:08 AM Anthony Clayden > wrote: > > > So the paper's main motivation is wrt Trac #9670. > > Are you sure you mean #9670? > Oops. Thanks for the catch Oliver. That should be #9627. (One of the tickets to do with FunDeps and type improvement ends in 70 ;-) AntC -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony_clayden at clear.net.nz Sun Dec 23 04:48:16 2018 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Sun, 23 Dec 2018 12:48:16 +0800 Subject: Equality constraints (~): type-theory behind them In-Reply-To: References: <7186c57d-3a79-91f8-0bcd-a9da3a8bd85a@gundry.co.uk> Message-ID: On Sat, 22 Dec 2018 at 7:08 PM, Anthony Clayden < anthony_clayden at clear.net.nz> wrote: > > On Mon, 10 Dec 2018 at 6:12 PM, Anthony Clayden < > anthony_clayden at clear.net.nz> wrote: > >> On Mon, 10 Dec 2018 at 9:36 PM, Tom Schrijvers wrote: >> >>> Maybe our Haskell'17 paper about Elaboration on Functional Dependencies >>> sheds some more light on your problem: >>> >>> https://people.cs.kuleuven.be/~tom.schrijvers/Research/papers/haskell2017a.pdf >>> >>> >> > I feel I'm not getting much light shed. No amount of adding `(~)` in GHC > nor `TypeCast`+`typeCast` method in Hugs will get #9627 function `f` to > compile. So my 'specific example' earlier in this thread shows `(~)` is > moderately eager/more eager than FunDeps alone, but not eager enough for > #9627. > Can anybody explain @yav's comment here https://github.com/ghc-proposals/ghc-proposals/pull/158#issuecomment-449590613 "currently equality constraints have no run-time evidence associated with them". Haskell has type-erasure semantics. Why would I need any _run-time_ evidence for anything to do with type improvement? What impact would the lack of evidence have at run-time? Does this mean `(~)` constraints don't produce evidence at compile time? Which is also the difficulty for type improvement under FunDeps. (I tried a type family to achieve the same effect as `(~)` with an injective TF. No improvement in improvement.) AntC > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Sun Dec 23 04:54:33 2018 From: allbery.b at gmail.com (Brandon Allbery) Date: Sat, 22 Dec 2018 23:54:33 -0500 Subject: Equality constraints (~): type-theory behind them In-Reply-To: References: <7186c57d-3a79-91f8-0bcd-a9da3a8bd85a@gundry.co.uk> Message-ID: I think the point is more that runtime evidence means passing an additional type witness around, potentially changing generated code and even behavior (if this causes dictionary passing where none had been needed previously). It's not addressing your question. On Sat, Dec 22, 2018 at 11:48 PM Anthony Clayden < anthony_clayden at clear.net.nz> wrote: > > > On Sat, 22 Dec 2018 at 7:08 PM, Anthony Clayden < > anthony_clayden at clear.net.nz> wrote: > >> >> On Mon, 10 Dec 2018 at 6:12 PM, Anthony Clayden < >> anthony_clayden at clear.net.nz> wrote: >> >>> On Mon, 10 Dec 2018 at 9:36 PM, Tom Schrijvers wrote: >>> >>>> Maybe our Haskell'17 paper about Elaboration on Functional Dependencies >>>> sheds some more light on your problem: >>>> >>>> https://people.cs.kuleuven.be/~tom.schrijvers/Research/papers/haskell2017a.pdf >>>> >>>> >>> >> I feel I'm not getting much light shed. No amount of adding `(~)` in GHC >> nor `TypeCast`+`typeCast` method in Hugs will get #9627 function `f` to >> compile. So my 'specific example' earlier in this thread shows `(~)` is >> moderately eager/more eager than FunDeps alone, but not eager enough for >> #9627. >> > > > Can anybody explain @yav's comment here > > https://github.com/ghc-proposals/ghc-proposals/pull/158#issuecomment-449590613 > "currently equality constraints have no run-time evidence associated with > them". > > Haskell has type-erasure semantics. Why would I need any _run-time_ > evidence for anything to do with type improvement? What impact would the > lack of evidence have at run-time? > > Does this mean `(~)` constraints don't produce evidence at compile time? > Which is also the difficulty for type improvement under FunDeps. > > (I tried a type family to achieve the same effect as `(~)` with an > injective TF. No improvement in improvement.) > > > AntC > >> > >> _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: