- ghc-devs - Haskell.org

please elaborate on comment for base:Data.Type.Equality.(==)?
by Nicolas Frisby 04 Feb '14

04 Feb '14

[CC'ing Richard, as I'm guessing he's the author of the comment.] I have a question regarding the comment on the type family Data.Type.Equality.(==). "A poly-kinded instance [of ==] is *not* provided, as a recursive definition for algebraic kinds is generally more useful." Can someone elaborate on "generally more useful". Thank you.

2 2

GHC boot-library package changelogs & release-notes
by Herbert Valerio Riedel 04 Feb '14

04 Feb '14

Hello fellow GHC devs, As some of you might have noticed, I added a changelog.md file to libraries/base: https://github.com/ghc/packages-base/blob/c8634027d4e3315a2276fb1be8168c486… (please feel free to fix any typos/omissions/whatever you notice) My hope/motivation is that since Hackage gained the ability to display changelog files, the rather extensive changes in `base` might be a bit more easily/conveniently accessible on Hackage. I chose to use Markdown format, as I believe it may be more convenient to maintain/edit the `base` changelog as plain text rather than having to edit XML after each noteworthy change in `base`. And as the release-notes typically only exploit a subset of the Docbook facilities, the conversion to Docbook XML could be performed semi-automatically shortly before a release. Moreover, the release notes from previous major GHC release (which in the past contained the major changes in `base` et al.) are usually removed again. While a separate changelog file would usually retain (more) version history. Therefore, I'd propose to switch from editing the user's guide release note for library release notes to using Hackage-changelog files in Markdown format (following a common structural convention) and make it the release-manager's responsibility to integrate the respective package's changelog content into the user's guide. Any comments? Cheers, hvr

4 3

TypeNats trial on new ghc branch 7.8
by Gabriel Riba 01 Feb '14

01 Feb '14

I know that the TypeNats solver may not have been merged with 7.8 branch but the compiler error looks so simple: Couldn't match type ‛(n + m) - 1’ with ‛(n - 1) + m’ --------------------------------- {-# LANGUAGE DataKinds, GADTs, KindSignatures, TypeOperators, PolyKinds, ExistentialQuantification #-} import GHC.TypeLits data Vect :: Nat -> * -> * where Nil :: Vect 0 a Cons :: a -> Vect (n-1) a -> Vect n a data MyProxy (n::Nat) = forall a. MyProxy (Vect n a) toProxy :: Vect (n::Nat) a -> MyProxy n toProxy v = MyProxy v len :: KnownNat n => Vect (n::Nat) a -> Integer len v = (natVal . toProxy) v -- Ok append :: Vect n a -> Vect m a -> Vect (n+m) a append Nil ys = ys append (Cons x xs) ys = Cons x (append xs ys) -- compiler error main = do print $ len Nil -- Ok print $ len (Cons (1::Int) Nil) -- Ok ------------------------------------------------------ Error on "append (Cons x xs) ys = ..." Couldn't match type ‛(n + m) - 1’ with ‛(n - 1) + m’ Expected type: Vect ((n + m) - 1) a Actual type: Vect ((n - 1) + m) a

4 3

Re: [commit: haddock] master: Update tests (18e9417)
by Gabor Greif 31 Jan '14

31 Jan '14

Unless I missed something big style, -XTypeHoles has been renamed to -XTypedHoles and not removed at all. Are you sure this patch is valid? Cheers, Gabor On 1/30/14, git(a)git.haskell.org <git(a)git.haskell.org> wrote: > Repository : ssh://git@git.haskell.org/haddock > > On branch : master > Link : > http://git.haskell.org/haddock.git/commitdiff/18e9417edcda21dd23edf675b41f4… > >>--------------------------------------------------------------- > > commit 18e9417edcda21dd23edf675b41f46ab336d773f > Author: Mateusz Kowalczyk <fuuzetsu(a)fuuzetsu.co.uk> > Date: Wed Jan 29 21:41:58 2014 +0000 > > Update tests > > This updates tests due to Haddock Trac #271 fix and due to removal of > TypeHoles as an extension from GHC. > > >>--------------------------------------------------------------- > > 18e9417edcda21dd23edf675b41f46ab336d773f > html-test/ref/Extensions.html | 2 +- > html-test/ref/Test.html | 2 +- > html-test/src/Extensions.hs | 2 +- > 3 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/html-test/ref/Extensions.html b/html-test/ref/Extensions.html > index 82fd732..382083c 100644 > --- a/html-test/ref/Extensions.html > +++ b/html-test/ref/Extensions.html > @@ -47,7 +47,7 @@ window.onload = function () > {pageLoad();setSynopsis("mini_Extensions.html");}; > ><th > >Extensions</th > ><td > - >TypeHoles</td > + >ExplicitForAll</td > ></tr > ></table > ><p class="caption" > diff --git a/html-test/ref/Test.html b/html-test/ref/Test.html > index 0214662..bd447ea 100644 > --- a/html-test/ref/Test.html > +++ b/html-test/ref/Test.html > @@ -41,7 +41,7 @@ window.onload = function () > {pageLoad();setSynopsis("mini_Test.html");}; > ><th > >License</th > ><td > - >(c) Simon Marlow 2002</td > + >BSD-style</td > ></tr > ><tr > ><th > diff --git a/html-test/src/Extensions.hs b/html-test/src/Extensions.hs > index 6b3535c..61eac21 100644 > --- a/html-test/src/Extensions.hs > +++ b/html-test/src/Extensions.hs > @@ -1,4 +1,4 @@ > -{-# LANGUAGE Haskell2010, TypeHoles, MonomorphismRestriction #-} > +{-# LANGUAGE Haskell2010, ExplicitForAll, MonomorphismRestriction #-} > {-# OPTIONS_HADDOCK show-extensions #-} > module Extensions where > > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits >

2 2

Re: 7.8 branch is created, HEAD is now open, and a note on merges
by Austin Seipp 31 Jan '14

31 Jan '14

(Grr, resending to list...) Hello all, The 7.8 branch is officially ready for RC1 (after some final Haddock bugs got quickly squashed by Gergo and Mateusz.) Pali, Luke - this is specifically for you two as you have offered to make the FreeBSD and iOS builds (Luke - 7.8 should contain both the fix for __thread and the perf-cross flavor, so it should work out of the box for you.) Attached is a fingerprint file for the GHC repository. You can restore it with: $ ./utils/fingerprint/fingerprint.py restore -f ghc-7.8-rc1.fingerprint See here for more details - https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources#Trackingth… Alternatively, simply checking out to the 'ghc-7.8' branch will result in the same thing - no new commits will go in until after RC1: $ git clone -b ghc-7.8 git://git.haskell.org/ghc ghc-7.8 $ cd ghc-7.8 $ ./sync-all get -b ghc-7.8 --extra --nofib Afterwords, just build and make the binaries as you normally would: $ ./boot; ./configure $ make $ make binary-dist Please let me know when the builds are done and somewhere to obtain them, and I'll upload them to haskell.org for the RC. I'll begin my builds now too... On Thu, Jan 30, 2014 at 5:02 PM, Austin Seipp <aseipp(a)pobox.com> wrote: > Hello all, > > The 7.8 branch is officially ready for RC1 (after some final Haddock > bugs got quickly squashed by Gergo and Mateusz.) > > Pali, Luke - this is specifically for you two as you have offered to > make the FreeBSD and iOS builds (Luke - 7.8 should contain both the > fix for __thread and the perf-cross flavor, so it should work out of > the box for you.) > > Attached is a fingerprint file for the GHC repository. You can restore it with: > > $ ./utils/fingerprint/fingerprint.py restore -f ghc-7.8-rc1.fingerprint > > See here for more details - > https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources#Trackingth… > > Alternatively, simply checking out to the 'ghc-7.8' branch will result > in the same thing - no new commits will go in until after RC1: > > $ git clone -b ghc-7.8 git://git.haskell.org/ghc ghc-7.8 > $ cd ghc-7.8 > $ ./sync-all get -b ghc-7.8 --extra --nofib > > Afterwords, just build and make the binaries as you normally would: > > $ ./boot; ./configure > $ make > $ make binary-dist > > Please let me know when the builds are done and somewhere to obtain > them, and I'll upload them to haskell.org for the RC. I'll begin my > builds now too... > > > On Thu, Jan 30, 2014 at 4:31 AM, Kazu Yamamoto <kazu(a)iij.ad.jp> wrote: >> Hello Herbert, >> >>> Hello Kazu, >>> >>> ..as this is a Cabal issue, this needs to be handled upstream; could you >>> please file an issue at >>> >>> https://github.com/haskell/cabal/issues/new >> >> Done. >> >> https://github.com/haskell/cabal/issues/1660 >> >> --Kazu >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs(a)haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> > > > > -- > Regards, > Austin - PGP: 4096R/0x91384671 -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

3 2

Re: 7.8 branch is created, HEAD is now open, and a note on merges
by Páli Gábor János 31 Jan '14

31 Jan '14

On Fri, Jan 31, 2014 at 12:02 AM, Austin Seipp <aseipp(a)pobox.com> wrote: > Please let me know when the builds are done and somewhere to obtain > them, and I'll upload them to haskell.org for the RC. I'll begin my > builds now too... All right, I have put the 32-bit and 64-bit FreeBSD builds here: http://haskell.inf.elte.hu/ghc/ Note that I included the corresponding SHA-256 checksum as well. Also, I composed a brief README for the users on how to install and use the binary distributions. Let me know if there is anything else I can do.

2 2

Re: 7.8 branch is created, HEAD is now open, and a note on merges
by Páli Gábor János 30 Jan '14

30 Jan '14

On Fri, Jan 31, 2014 at 12:02 AM, Austin Seipp <aseipp(a)pobox.com> wrote: > The 7.8 branch is officially ready for RC1 (after some final Haddock > bugs got quickly squashed by Gergo and Mateusz.) Excellent, folks! > Alternatively, simply checking out to the 'ghc-7.8' branch will result > in the same thing - no new commits will go in until after RC1: > > $ git clone -b ghc-7.8 git://git.haskell.org/ghc ghc-7.8 > $ cd ghc-7.8 > $ ./sync-all get -b ghc-7.8 --extra --nofib For some reason, I get this for the last command: == running git clone git://git.haskell.org/libffi-tarballs.git libffi-tarballs -b ghc-7.8 --extra --nofib error: unknown option `extra'

2 1

7.8 branch is created, HEAD is now open, and a note on merges
by Austin Seipp 30 Jan '14

30 Jan '14

Hello all, I've just created the 7.8 branch after tying off some of the final loose ends. In its current state, I expect the branch as it is now to become RC1 within the day. I plan on starting builds for the following soon: - OS X 10.7 and OS X 10.9 - Linux i386/amd64 (likely based on Debian Wheezey) - Windows i386/amd64 (many thanks to Kyrill Briantsev for the heroic last-minute linker fixes!) I'll send a (GPG-signed) email containing SHA1 hashes when they're done. Two systems I won't make builds for RC1 by default (but could be persuaded to if nobody else does, and people want it): - Older glibc-2.5 based systems (e.g. CentOS, - a few users have talked about this wrt binary releases, where I don't think GHC works.) - FreeBSD - Pali, if you'd like to do this, feel free, and let me know. This means I'll (mostly) be waiting around today, so feel free to shoot questions. As of now, this means HEAD is now version 7.9, and you're free to push wacky experiments or changes now, if you've been holding off. You'll probably want to clean your whole tree, since this means the interface file versions etc will change. Finally, we picked up a good amount of new committers this year, so let's remind people of the merging policy: what happens if you need to merge something you did to the 7.8 branch? There are two main avenues for this to happen: * Someone reports a bug against the 7.8 RC on Trac. You decide to fix it and do so. Now what? 1) Please commit the bug to master, and confirm it's a fix. 2) Go to the bug, and instead of closing it, change the ticket status to 'merge'. 3) I will cherry-pick it over to the 7.8 branch for you - nothing else needed. * There's not a recorded bug, but you do push a change, and you think it should be merged (maybe a typo or something.) In this case, I'd ask you please CC me on the email sent to ghc-commits(a)haskell.org which is related to your commit, and just say "Please merge" or somesuch. I'll come over the commits with such a response. This goes for all changes - submodule updates, typos, real fixes, etc. It's likely me and Herbert will restrict the Gitolite permissions to only allow the two of us to touch the ghc-7.8 branch. So it's really important you put us in the loop, ASAP. If you don't do one of these two things, it's highly likely I will miss it, and not merge it. If you have questions, please ask me or Herbert. If there's a merge conflict, we can discuss it. Thanks -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

5 11

GHC for iOS (arm) 7.8 Preview Build ready for upload
by Luke Iannini 30 Jan '14

30 Jan '14

Hi folks! I've just finished a preview build of GHC for iOS off the 7.8 branch, but could use a place to upload it. And once that's done, if anyone would like to help me test it that has Xcode 5 and a device, that would be excellent! Cheers Luke

1 1

Unit tests for GHC code?
by Joachim Breitner 30 Jan '14

30 Jan '14

Hi, I am currently working on a piece of code (an analysis to solve #7994) where I’d like to make sure that my changes do not regress over what I had before. But I find it unnecessarily hard to write our usual test-case styles for them: * I’d like to test against very small Core that does not involve anything unnecessary. But it is hard to write Haskell that has, when it hits my analysis, this shape. It requires lots of {-# NOINLINE #-} and other tricks. * To test the result, I either have to write a performance test, but it is not always easy to come up with a program where the gains are massive enough to become a reliable test. It is possible, but work, and doing it maybe half a dozen times for various inputs is tricky. * Alternative, I can dump the Core and add that to the test cases. But now other changes to the compiler can easily trigger my test case failing. So I thought about writing a test case that simply imports my module from the ghc library, generates artificial, minimal core, and checks the output for precisely what I want (in my case, some fields of the IdInfo of various binders). I don’t see any examples for that in the test suite. Is that just because noone has done that before, or is there inherently bad about this approach that we do _not_ want to that? Also, we don’t have a parser for Core, so I’ll have to build my syntax trees using the stuff from MkCore et al, right? Thanks, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nomeata(a)debian.org

5 7