From ben at well-typed.com Mon Apr 18 19:54:44 2016 From: ben at well-typed.com (Ben Gamari) Date: Mon, 18 Apr 2016 21:54:44 +0200 Subject: [ANNOUNCE] GHC 8.0.1 release candidate 3 available Message-ID: <87d1pmvgjf.fsf@smart-cactus.org> Hello Haskellers, The GHC team is happy to announce the availability of third release candidate of the Glasgow Haskell Compiler's 8.0.1 release. Source and binary distributions can be found at, http://downloads.haskell.org/~ghc/8.0.1-rc3/ This is the third of what will be four candidates leading up to the 8.0.1 release. As there are a number of known issues with this candidate, we expect to produce the fourth and final release candidate shortly. While we considered not releasing this candidate at all and instead skipping to rc4, we decided that it would be helpful to make it available despite its issues to increase the likelihood of catching any remaining bugs. That being said, this candidate lacks the range of binary distributions which we usually offer, * We are unable to release Windows bindists due to a compatibility issue which we didn't catch until after preparing the source distribution. * Binaries targeting Redhat distributions are currently not available Regardless, users for whom a distribution is available are encouraged to try this candidate as it fixes dozens of issues present in release candidate two. These include, * A type-checker panic triggered by use of Typeable on a kind-polymorphic type constructor (#11334) * A type-checker explosion where -XTypeInType would gobble up massive amounts of memory when used in a data instance (#11407) * Various issues involving unexpected laziness resulting in exception handlers not being invoked (#11555) * GHC now fails more gracefully when used with an older cabal-install release (#11558) * TypeInType now has proper documentation in the users guide (#11614) * The story surrounding type `RuntimeRep`s (formerly known as `Levity`) is now far better developed, closing several doors to unsafe behavior that TypeInType previously opened (#11473, #11723) * A long-standing bug in the constant-folding rules for `mod` for the `Word` type has been resolved (#11702) * Various issues introduced by OverloadedRecordFields have been fixed (#11662, #11401) * A regression in the typechecker resulting in the rejection of code in the `free` and `microlens` packages has been fixed (#11608) * A bug in the LLVM code generator which caused some programs to emit unbuildable LLVM IR has been fixed (#11649) * A bug where pattern synonyms defined in terms of a pattern match on a record would be rejected if the fields weren't written in the same order as they were defined has been resolved (#11633) * A bug in the runtime system's treatment of weak references which could result in segmentation faults in some cases has been fixed (#11108) * a variety of optimizations improving compiler performance have been merged * and many others Mac OS X users should be aware that the recent XCode 7.3 release ships with a broken `nm` utility which breaks the GHC build (#11744, #11823). Unfortunately, this candidate does not notice this brokenness and odd behavior can result. OS X users running XCode 7.3 are encouraged to open a ticket with Apple and build GHC with the `--with-nm=nm-classic` configure option until a fix is available. As mentioned earlier, there are a number of known issues with this candidate which will be addressed in release candidate four. These issues include, * A number of typechecker bugs (#11811, #11797, #11813, #11814) * A build issue seen on OS X (#11828) * Template Haskell lacks the ability to produce instances with OVERLAPP{ING,ABLE,ED} pragmas * Autoconf has inadequate version checks for libdw (#11820) * Typeable and hs-boot files interact poorly (#11824) * The build system doesn't check for the broken Apple `nm` utility, leading to unpredictable results (#11823, #11744) We hope to have release candidate four available by the middle of next week. Thanks to everyone who has contributed code, testing, builds, and bug reports thusfar! Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From juhpetersen at gmail.com Sat Apr 23 14:16:17 2016 From: juhpetersen at gmail.com (Jens Petersen) Date: Sat, 23 Apr 2016 23:16:17 +0900 Subject: [ANNOUNCE] GHC 8.0.1 release candidate 3 available In-Reply-To: <87d1pmvgjf.fsf@smart-cactus.org> References: <87d1pmvgjf.fsf@smart-cactus.org> Message-ID: On 19 April 2016 at 04:54, Ben Gamari wrote: > The GHC team is happy to announce the availability of third release > candidate of the Glasgow Haskell Compiler's 8.0.1 release. Source and > binary distributions can be found at, > > http://downloads.haskell.org/~ghc/8.0.1-rc3/ Thank you! Sorry for the delay I have now done perf builds in my Fedora Copr: https://copr.fedorainfracloud.org/coprs/petersen/ghc-8.0.1/ Jens ps next onto RC4. :) From anthony_clayden at clear.net.nz Tue Apr 26 08:20:31 2016 From: anthony_clayden at clear.net.nz (AntC) Date: Tue, 26 Apr 2016 08:20:31 +0000 (UTC) Subject: Magic classes for Overloaded Record Fields, overlaps, FunDeps Message-ID: There's an intriguing comment here wrt anonymous records: https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/ MagicClasses#Designextension:anonymousrecords (End of the section) "... this doesn't quite work, because the two instances overlap, but it is possible with a bit more trickery" I could well understand if everybody's forgotten what was the "trickery", because ORF has been so long in the pipeline, but could anyone explain? Reason for the q: I'm looking at anonymous records myself, including extending, shortening and joining anon records. And yes overlapping instances are everywhere. Using type families isn't being too ergonomic. And I notice ORF has used FunDeps. But for me, FunDeps in the HList style is also rather ugly. Is there some trickery I'm missing? Thanks AntC From adam at well-typed.com Tue Apr 26 12:24:58 2016 From: adam at well-typed.com (Adam Gundry) Date: Tue, 26 Apr 2016 13:24:58 +0100 Subject: Magic classes for Overloaded Record Fields, overlaps, FunDeps In-Reply-To: References: Message-ID: Hi AntC, On 26/04/16 09:20, AntC wrote: > There's an intriguing comment here wrt anonymous records: > https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/ > MagicClasses#Designextension:anonymousrecords > (End of the section) > > "... this doesn't quite work, because the two instances overlap, > but it is possible with a bit more trickery" > > I could well understand if everybody's forgotten what was the "trickery", > because ORF has been so long in the pipeline, but could anyone explain? I'm afraid the sentence on the wiki page is slightly misleading, as it dates from the type families version of the HasField proposal, rather than the functional dependencies version, and the page hasn't been updated properly. In fact, with the change to functional dependencies, the overlapping instances solution works rather nicely, in that it works if the field labels are distinct and reports an error if not [1]. I'll update the page. I have been vacillating between type families and fundeps for the ORF classes. I hadn't fully appreciated this point about overlap, but I think it is a reason to prefer fundeps, which is the direction in which I'm leaning. I'd be grateful for feedback on this issue though! > Reason for the q: I'm looking at anonymous records myself, > including extending, shortening and joining anon records. > And yes overlapping instances are everywhere. > > Using type families isn't being too ergonomic. And I notice ORF has used FunDeps. > But for me, FunDeps in the HList style is also rather ugly. > > Is there some trickery I'm missing? In general, to avoid overlapping instances, one trick is to introduce a closed type family that discriminates between the parameters, along with an auxiliary class whose instances match on the result of the type family. For example, rather than instance C [Int] instance C [a] one can write class IsInt a ~ b => CHelper a b instance CHelper Int True instance IsInt a ~ False => CHelper a False type family IsInt a where IsInt Int = True IsInt a = False instance CHelper a (IsInt a) => C [a] This allows one to write instances using top-to-bottom matching, like closed type families, provided all the instances are declared together. Hope this helps, Adam P.S. If you have any thoughts on the interaction between ORF and encodings of anonymous records, I'd be interested to hear them. [1] https://gist.github.com/adamgundry/7292df8cef62fd6750885be3f5f892e7 -- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From anthony_clayden at clear.net.nz Wed Apr 27 01:55:00 2016 From: anthony_clayden at clear.net.nz (AntC) Date: Wed, 27 Apr 2016 01:55:00 +0000 (UTC) Subject: Magic classes for Overloaded Record Fields, overlaps, FunDeps References: Message-ID: > > On 26/04/16 09:20, AntC wrote: > > There's an intriguing comment here wrt anonymous records: ... > > I'm afraid the sentence on the wiki page is slightly misleading, ... > with the change to functional dependencies, > the overlapping instances solution works rather nicely, > in that it works if the field labels are distinct > and reports an error if not [1]. Thanks Adam, we're very much thinking along the same lines. Yes that's exactly where I am at. I too like the error message re overlapping instances. Contrast that for an HList style solution, you get instance match on the leftmost/outermost appearance of the label. So to detect duplicates you need a `Lacks` superclass constraint on the HList's tail. And to get `Lacks` to work, you need to create an instance; for which you then need an impossible-to-fulfill superclass constraint. Even with the best of documentation, you get a dense error message, quite possibly pointing to the wrong place. So unlike HLists, Nikita's Records are 'flat' (same as if you used plain tuples) and the instance matcher can look at all elements at the same time. Furthermore (closed) type families suffer a similar difficulty. The instance equations are ordered, so will pick the leftmost (or rightmost) appearance without complaint. To detect ambiguous getFields you need first a guard equation HasField n1 (Record2 n1 v1 n1 v2) = error: overlap For a two-tuple that's OK. For more than two you need guard equations for all of the ambiguous perms and combs. For a 24-tuple that's horrendous. For tuple extension or joining your head explodes. Even if we could automate generating the ambig instances somehow, it just feels wrong to get an instance/equation match when what you want is an error. > > I have been vacillating between type families and fundeps for the ORF > classes. I hadn't fully appreciated this point about overlap, but I > think it is a reason to prefer fundeps, which is the direction in which > I'm leaning. I'd be grateful for feedback on this issue though! > Yes, this seems a 'featurette' of Overlaps/FunDeps compared to closed type families. Should I regard it as a 'happy accident' that might stop working some day? It does seem a pretty fundamental requirement for Overlaps -- providing of course IncoherentInstances is never switched on in some distant module. > > In general, to avoid overlapping instances, one trick is to introduce a > closed type family that discriminates between the parameters, > along with an auxiliary class whose instances match > on the result of the type family. ... Thanks. Yes I'm aware of that approach from HList. It works a little more nicely with type families. The difficulty remains that as soon as you want overlaps in such a way that takes you to FunDeps, it's very difficult to 'mix modes' with type families. AntC > > [1] https://gist.github.com/adamgundry/7292df8cef62fd6750885be3f5f892e7 > From simonpj at microsoft.com Wed Apr 27 11:14:27 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 27 Apr 2016 11:14:27 +0000 Subject: Magic classes for Overloaded Record Fields, overlaps, FunDeps In-Reply-To: References: Message-ID: <94809e65f6204690a6059842f7847c95@DB4PR30MB030.064d.mgd.msft.net> | > I have been vacillating between type families and fundeps for the ORF | > classes. I hadn't fully appreciated this point about overlap, but I | > think it is a reason to prefer fundeps, which is the direction in | > which I'm leaning. I'd be grateful for feedback on this issue though! ... | The difficulty remains that as soon as you want overlaps in such a way | that takes you to FunDeps, it's very difficult to 'mix modes' with type | families. Can one give a standalone explanation of the fundep/type-family/overlap issue here? Or is it explained on a wiki page? Simon From anthony_clayden at clear.net.nz Thu Apr 28 02:03:30 2016 From: anthony_clayden at clear.net.nz (AntC) Date: Thu, 28 Apr 2016 02:03:30 +0000 (UTC) Subject: Magic classes for Overloaded Record Fields, overlaps, FunDeps References: Message-ID: > Adam Gundry well-typed.com> writes: > ... > > P.S. If you have any thoughts on the interaction between ORF and > encodings of anonymous records, I'd be interested to hear them. Are you sure you want to open up that question? ;-) Nikita's record library has certainly given food for thought. Before we start into anonymous records, I think we should figure out the path that gets to extensible records, truncatable records, mergable records, joinable records, ... So I'm worried about comments from Nikita that extensibility is beyond what's possible under that approach. In considering that, I'm not sure that "anonymous records" are very much like H98 field-labelled data types. (Which is to say H98 records are not very much like records ;-) Trouble is, H98 records have gobbled up so much of the available syntax. Let's frame the requirement instead as 'labelled tuples'. Then I'm looking greedily at round-bracket syntax: ( name = "Fred", birthday = (day = 28, month = 4, year = 2016) ) I don't know how much Nikita was limited by what's possible with src-xtns, so I won't bikeshed more about syntax. Can we use the same ORF mechanisms under the covers for both labelled tuples and records? Certainly it would be nice to support intra-conversion routines: labelledDT = fromLabels ( name = ... ) labelledTuple = toLabels labelledDT I rather think I don't care about the implementation of access -- that is, whether lenses and which style of lens -- providing it just works. (And doesn't give impenetrable error messages. That's a bit of a worry with all this higher-kinded engineering going on in GHC 8.0. Will ORF's 'Magic Type Classes' have bit-rotted by the time you get to release them? Do we call that R.Eisenberg uncertainty? ;-) Now if you have a label "birthday", you probably want the field to hold a Date, not just some arbitrary type 'a'. And that's what I find unergonomic about the label-as-Symbol approach. (For Nikita's records you give a type for the field alongside the label in the record signature. But why the need to state the obvious, and repeat it for every record that uses "birthday"?) The labelled "birthday = ..." approach seems tantalisingly close to data constructors: ( Name "Fred", Birthday $ Date 28 4 2016 ) Which takes us (perhaps) to HLIst-style Type-Indexed Products. How could they fit with ORF? Perhaps introduce an implicit label spelled same as the Data Constructor? Except starting lower case, otherwise the #name prefix will throw a wobbly. What gave me a queasy feeling looking at Nikita's Records is the alternating labels and data type. :: Record2 "name" String "birthday" Date I'd rather see explicit pairing of label and data. newtype Label (l :: Symbol) a = Label a rec :: Record2 (Label "name" String, Label "birthday" Date) The newtype should mean zero runtime cost. I can see a couple of reasons behind Nikita's approach that might have been getting in the way of that. Sequencing the labels into alphabetic order. (Which is probably to implement the second reason.) Now certainly we want the label position to be arbitrary in anonymous records. But that's just a bit of representation hiding. Resequencing them alphabetically means they show in a probably unmeaningful format. It also might be getting in the way of extensibility. To compare two records with the same labels, does need the fields in the same seq. We could do that with: labelledTuple `asLabelSeqOf`canonicalLabels The second reason would be to check for duplicate labels. Hmm is that essential? YMMV As far as I can see, duplicate labels within a tuple are only problematic when you want to get/set a field by that label. Your example [1] isn't upset by: z4 = getField (proxy# :: Proxy# "bar") (Record3 True False "ok" :: Record3 "foo" Bool "foo" Bool "bar" String) Again if it is a requirement, it's easy enough to build a smart constructor wrapper that validates for duplicate labels, ? la HList. Did that answer (any of) your question? AntC > > [1] https://gist.github.com/adamgundry/7292df8cef62fd6750885be3f5f892e7 > From anthony_clayden at clear.net.nz Thu Apr 28 05:38:43 2016 From: anthony_clayden at clear.net.nz (AntC) Date: Thu, 28 Apr 2016 05:38:43 +0000 (UTC) Subject: Magic classes for Overloaded Record Fields, overlaps, FunDeps References: Message-ID: > > The labelled "birthday = ..." approach seems > tantalisingly close to data constructors: > ( Name "Fred", Birthday $ Date 28 4 2016 ) > > Which takes us (perhaps) to HLIst-style > Type-Indexed Products. > How could they fit with ORF? > Perhaps introduce an implicit label spelled same as the Data Constructor? Errk! That should be Type Constructor. (I'm expecting these would be newtypes with the Data Constructor punning on the Type.) Thinking on ... Having been unkind about the higher-kinded stuff, [I withdraw and apologise.] I wonder if we could use it? Does this have any likelihood of working? import Data.Kind class IskLabel k (x :: k) a where fromkLabel :: Proxy# x -> a instance IskLabel Symbol x (r -> a) where ... -- indexing by label instance IskLabel (Type -> Type) t (r -> a) where ... -- indexing by Type Constructor > Except starting lower case, > otherwise the #name prefix will throw a wobbly. ??Is that actually true? H98 field labels must be lower case, so all the examples are. But Symbol can be upper?? AntC From ben at well-typed.com Thu Apr 28 09:10:13 2016 From: ben at well-typed.com (Ben Gamari) Date: Thu, 28 Apr 2016 11:10:13 +0200 Subject: [ANNOUNCE] GHC 8.0.1 release candidate 4 available Message-ID: <87wpnim74a.fsf@smart-cactus.org> Hello Haskellers, The GHC team is happy to announce the availability of fourth release candidate of the Glasgow Haskell Compiler's 8.0.1 release. Source and binary distributions can be found at, http://downloads.haskell.org/~ghc/8.0.1-rc4/ This is the last of four candidates leading up to the 8.0.1 release, addressing nearly all of the known issues of the previous candidates. These include, * A type-checker panic triggered by use of Typeable on a kind-polymorphic type constructor (#11334) * A type-checker explosion where -XTypeInType would gobble up massive amounts of memory when used in a data instance (#11407) * A variety of other typechecker issues (#11811, #11797, #11813, #11814) * A build issue seen on OS X (#11828) * Template Haskell can now produce instances with OVERLAPP{ING,ABLE,ED} pragmas * Autoconf has improved version checks for libdw (#11820) * Typeable and hs-boot files now interact nicely (#11824) * The build system now checks for the broken Apple `nm` utility (#11823, #11744) * Various issues involving unexpected laziness resulting in exception handlers not being invoked (#11555) * GHC now fails more gracefully when used with an older cabal-install release (#11558) * TypeInType now has proper documentation in the users guide (#11614) * The story surrounding type `RuntimeRep`s (formerly known as `Levity`) is now far better developed, closing several doors to unsafe behavior that TypeInType previously opened (#11473, #11723) * A long-standing bug in the constant-folding rules for `mod` for the `Word` type has been resolved (#11702) * Various issues introduced by OverloadedRecordFields have been fixed (#11662, #11401) * A regression in the typechecker resulting in the rejection of code in the `free` and `microlens` packages has been fixed (#11608) * A bug in the LLVM code generator which caused some programs to emit unbuildable LLVM IR has been fixed (#11649) * A bug where pattern synonyms defined in terms of a pattern match on a record would be rejected if the fields weren't written in the same order as they were defined has been resolved (#11633) * A bug in the runtime system's treatment of weak references which could result in segmentation faults in some cases has been fixed (#11108) * a variety of optimizations improving compiler performance have been merged * and many others Mac OS X users should be aware that the recent XCode 7.3 release ships with a broken `nm` utility which breaks the GHC build (#11744, #11823). The build system will check for this condition and request that the tree is configured to use the `nm-classic` utility if found. OS X users running XCode 7.3 are encouraged to open a ticket with Apple so that this issue may be fixed in future XCode releases. If no major issues pop up we expect that this will be the last release candidate before the final release, which we hope to push out in the coming weeks. Thanks to everyone who has contributed code, testing, builds, and bug reports thusfar! Cheers and happy testing, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From takenobu.hs at gmail.com Fri Apr 29 05:17:36 2016 From: takenobu.hs at gmail.com (Takenobu Tani) Date: Fri, 29 Apr 2016 14:17:36 +0900 Subject: [ANNOUNCE] GHC 8.0.1 release candidate 4 available In-Reply-To: <87wpnim74a.fsf@smart-cactus.org> References: <87wpnim74a.fsf@smart-cactus.org> Message-ID: Hi Ben, Richard and GHC team, I appreciate your great effort. The rc4 simply represents `$` type in ghci. $ ./ghcii.sh GHCi, version 8.0.0.20160421: http://www.haskell.org/ghc/ :? for help Prelude> :t ($) ($) :: (a -> b) -> a -> b Newcomers may love it :) Thank you very much, Takenobu 2016-04-28 18:10 GMT+09:00 Ben Gamari : > > Hello Haskellers, > > The GHC team is happy to announce the availability of fourth release > candidate of the Glasgow Haskell Compiler's 8.0.1 release. Source and > binary distributions can be found at, > > http://downloads.haskell.org/~ghc/8.0.1-rc4/ > > This is the last of four candidates leading up to the 8.0.1 release, > addressing nearly all of the known issues of the previous candidates. > These include, > > * A type-checker panic triggered by use of Typeable on a > kind-polymorphic type constructor (#11334) > > * A type-checker explosion where -XTypeInType would gobble up massive > amounts of memory when used in a data instance (#11407) > > * A variety of other typechecker issues (#11811, #11797, #11813, > #11814) > > * A build issue seen on OS X (#11828) > > * Template Haskell can now produce instances with > OVERLAPP{ING,ABLE,ED} pragmas > > * Autoconf has improved version checks for libdw (#11820) > > * Typeable and hs-boot files now interact nicely (#11824) > > * The build system now checks for the broken Apple `nm` utility > (#11823, #11744) > > * Various issues involving unexpected laziness resulting in exception > handlers not being invoked (#11555) > > * GHC now fails more gracefully when used with an older cabal-install > release (#11558) > > * TypeInType now has proper documentation in the users guide (#11614) > > * The story surrounding type `RuntimeRep`s (formerly known as > `Levity`) is now far better developed, closing several doors to > unsafe behavior that TypeInType previously opened (#11473, #11723) > > * A long-standing bug in the constant-folding rules for `mod` for the > `Word` type has been resolved (#11702) > > * Various issues introduced by OverloadedRecordFields have been fixed > (#11662, #11401) > > * A regression in the typechecker resulting in the rejection of code > in the `free` and `microlens` packages has been fixed (#11608) > > * A bug in the LLVM code generator which caused some programs to emit > unbuildable LLVM IR has been fixed (#11649) > > * A bug where pattern synonyms defined in terms of a pattern match on > a record would be rejected if the fields weren't written in the same > order > as they were defined has been resolved (#11633) > > * A bug in the runtime system's treatment of weak references which > could result in segmentation faults in some cases has been fixed > (#11108) > > * a variety of optimizations improving compiler performance have been > merged > > * and many others > > Mac OS X users should be aware that the recent XCode 7.3 release ships > with a broken `nm` utility which breaks the GHC build (#11744, #11823). > The build system will check for this condition and request that the tree > is configured to use the `nm-classic` utility if found. OS X users > running XCode 7.3 are encouraged to open a ticket with Apple so that > this issue may be fixed in future XCode releases. > > If no major issues pop up we expect that this will be the last release > candidate before the final release, which we hope to push out in the > coming weeks. Thanks to everyone who has contributed code, testing, > builds, and bug reports thusfar! > > Cheers and happy testing, > > - Ben > > _______________________________________________ > 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 juhpetersen at gmail.com Fri Apr 29 09:12:38 2016 From: juhpetersen at gmail.com (Jens Petersen) Date: Fri, 29 Apr 2016 18:12:38 +0900 Subject: [ANNOUNCE] GHC 8.0.1 release candidate 4 available In-Reply-To: <87wpnim74a.fsf@smart-cactus.org> References: <87wpnim74a.fsf@smart-cactus.org> Message-ID: On 28 April 2016 at 18:10, Ben Gamari wrote: > The GHC team is happy to announce the availability of fourth release > candidate of the Glasgow Haskell Compiler's 8.0.1 release. Thank you! I almost finished the Fedora/RHEL building in time in my Fedora Copr repo: https://copr.fedorainfracloud.org/coprs/petersen/ghc-8.0.1/ Jens