Haskell Platform Update?
Hi all. I was just wondering if an updated release for the Haskell Platform was planned in the neat future? The current schedule lists November of last year as being the time for release candidates.. Thanks, ~Caitlin ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Haskell Platform Update?
On Friday 30 May 2014, 23:42:57, Caitlin wrote: Hi all. I was just wondering if an updated release for the Haskell Platform was planned in the neat future? The current schedule lists November of last year as being the time for release candidates.. Thanks, ~Caitlin Yes, the preparations are in progress. I can't tell if it's going to be released really soon (next week) or within the next month, or whether something again throws a spanner into the works and it takes longer. The delay is in no small part due to the release of GHC 7.8 having been delayed for a nontrivial amount of time. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8.3 release
+1 Stability is very important. Also, do we have an ETA for when we will have an improved infrastructure for automated builds and the associated tests. I think this would help a lot with stability and shorten the time to the next release. On Fri, May 30, 2014 at 6:46 PM, Simon Marlow marlo...@gmail.com wrote: On 27/05/14 09:06, Austin Seipp wrote: PPS: This might also impact the 7.10 schedule, but last Simon and I talked, we thought perhaps shooting for ICFP this time (and actually hitting it) was a good plan. So I'd estimate on that a 7.8.4 might happen a few months from now, after summer. FWIW, I think doing 7.10 in October is way too soon. Major releases create a large distributed effort for package maintainers and users, and there are other knock-on effects, so we shouldn't do them too often. A lot of our users want stability, while many of them also want progress, and 12 months between major releases is the compromise we settled on. The last major release slipped for various reasons, but I don't believe that means we should try to get back on track by having a short time between 7.8 and 7.10. 7.8 will be out of maintenance when it has only just made it into a platform release. Anyway, that's my opinion. Of course if everyone says they don't mind a 7.10 in October then I withdraw my objection :-) (as a data point, upgrading to 7.8 at work cost me three weeks, but we're probably a special case) Cheers, Simon ___ ghc-devs mailing list ghc-d...@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8.3 release
For me upgrading to 7.8 was very easy. The release slippage actually helped out with that. 7.8 had already been specified well enough and already had some active users for a long time. This made for a long window for package maintainers to update their packages to have 7.8 compatibility. Perhaps October is a good timeline to try to cut an initial alpha release that specifies the interface for package authors to compile against, but the actual release can wait until later. On Fri, May 30, 2014 at 2:46 PM, Simon Marlow marlo...@gmail.com wrote: On 27/05/14 09:06, Austin Seipp wrote: PPS: This might also impact the 7.10 schedule, but last Simon and I talked, we thought perhaps shooting for ICFP this time (and actually hitting it) was a good plan. So I'd estimate on that a 7.8.4 might happen a few months from now, after summer. FWIW, I think doing 7.10 in October is way too soon. Major releases create a large distributed effort for package maintainers and users, and there are other knock-on effects, so we shouldn't do them too often. A lot of our users want stability, while many of them also want progress, and 12 months between major releases is the compromise we settled on. The last major release slipped for various reasons, but I don't believe that means we should try to get back on track by having a short time between 7.8 and 7.10. 7.8 will be out of maintenance when it has only just made it into a platform release. Anyway, that's my opinion. Of course if everyone says they don't mind a 7.10 in October then I withdraw my objection :-) (as a data point, upgrading to 7.8 at work cost me three weeks, but we're probably a special case) Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8.3 release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/31/2014 12:28 PM, George Colpitts wrote: +1 Stability is very important. Also, do we have an ETA for when we will have an improved infrastructure for automated builds and the associated tests. I think this would help a lot with stability and shorten the time to the next release. On Fri, May 30, 2014 at 6:46 PM, Simon Marlow marlo...@gmail.com mailto:marlo...@gmail.com wrote: On 27/05/14 09:06, Austin Seipp wrote: PPS: This might also impact the 7.10 schedule, but last Simon and I talked, we thought perhaps shooting for ICFP this time (and actually hitting it) was a good plan. So I'd estimate on that a 7.8.4 might happen a few months from now, after summer. FWIW, I think doing 7.10 in October is way too soon. Major releases create a large distributed effort for package maintainers and users, and there are other knock-on effects, so we shouldn't do them too often. A lot of our users want stability, while many of them also want progress, and 12 months between major releases is the compromise we settled on. The last major release slipped for various reasons, but I don't believe that means we should try to get back on track by having a short time between 7.8 and 7.10. 7.8 will be out of maintenance when it has only just made it into a platform release. Anyway, that's my opinion. Of course if everyone says they don't mind a 7.10 in October then I withdraw my objection :-) (as a data point, upgrading to 7.8 at work cost me three weeks, but we're probably a special case) Cheers, Simon Hi George: There are continuous builds of GHC HEAD on several platforms and architectures: http://haskell.inf.elte.hu/builders/ There are still some bugs to work out there for sure (particularly mine on SmartOS), but a lot of progress has been made. The most critical gap is the lack of Windows and OS X builders since they are Tier 1 platforms for GHC. If you have Windows or OS X machines available please consider offering a builder: https://ghc.haskell.org/trac/ghc/wiki/Builder Best, Alain -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEbBAEBAgAGBQJTikGBAAoJEP0rIXJNjNSA/KsH+I7mug5uqHDr5YzZJSPl0awS 1PudhQqnBLf8Op/IQuPR7lYZEsXNTUb+VU1vV0vEo8+nRAaueVlhffsXYe7YRRHF wQqA1WsmIfwwDsU2DkeVOhKMht9iB1eKC3vvsTEvZE8GJKvQZDTIeas5QtUki/i0 yuTPrRMZjf6IubsxeY90mlDCgpRMjRIWcRPm9fWj7c0wdzUNmMR0IPshMiXjZbbM US9hkoyuXUyYZrtn19vbPGNTss3gZJEqengyDNDyVNrEd4QXC8Us/dqbnbjrKPI3 8D9BbVTOyELJ44mFXmlcXT8DSfIYCAv/sS81sXNm4lQX3jhTOyx2hNa3jvqIrQ== =sZkd -END PGP SIGNATURE- ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Data.Type.Equality.== works better when used at kind * - * - Bool
On May 31, 2014, at 1:12 AM, adam vogt vogt.a...@gmail.com wrote: are there instances of (==) that behave differently from the poly-kinded version? Yes. To be concrete, here would be the polykinded instance: type family EqPoly (a :: k) (b :: k) where EqPoly a a = True EqPoly a b = False type instance (a :: k) == (b :: k) = EqPoly a b Note that this overlaps with every other instance -- if this were defined, it would be the only instance for (==). Now, consider data Nat = Zero | Succ Nat Suppose I want foo :: (Succ n == Succ m) ~ True = ((n == m) :~: True) foo = Refl This would not type-check with the poly-kinded instance. `Succ n == Succ m` quickly becomes `EqPoly (Succ n) (Succ m)` but then is stuck. We don't know enough about `n` and `m` to reduce further. On the other hand, consider this: type family EqNat (a :: Nat) (b :: Nat) where EqNat Zero Zero = True EqNat (Succ n) (Succ m) = EqNat n m EqNat nm= False type instance (a :: Nat) == (b :: Nat) = EqNat a b With this instance, `foo` type-checks fine. `Succ n == Succ m` becomes `EqNat (Succ n) (Succ m)` which becomes `EqNat n m`. Thus, we can conclude `(n == m) ~ True` as desired. So, the Nat-specific instance allows strictly more reductions, and is thus preferable to the poly-kinded instance. But, if we introduce the poly-kinded instance, we are barred from writing the Nat-specific instance, due to overlap. Even better than the current instance for * would be one that does this sort of recursion for all datatypes, something like this: type family EqStar (a :: *) (b :: *) where EqStar Bool Bool = True EqStar (a,b) (c,d) = a == c b == d EqStar (Maybe a) (Maybe b) = a == b ... EqStar a b = False The problem is the (...) is extensible -- we would want to add new cases for all datatypes in scope. This is not currently possible for closed type families. Perhaps it would be an improvement to write the cases for all types in scope in Data.Type.Equality -- that is, the types exported from `base`. I hope this is helpful. In any case, I will put some of the text in this email into the comments in Data.Type.Equality for the next person who looks. Richard ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
