On Monday 27 September 2010 12:58:08, Christian Maeder wrote:

I've tried to install HTTP (for cabal-install) and get the following error:

Configuring HTTP-4000.0.9... Setup: At least the following dependencies are missing: base ==3.*

What is the problem? The Build-depends of HTTP's cabal file look correct (and fulfilled): Build-depends: base >= 3, array, old-time, bytestring

Cheers Christian

Probably it's the preferred versions on hackage: -- A global set of preferred versions. -- -- This is to indicate a current recommended version, to allow stable and -- experimental versions to co-exist on hackage and to help transitions -- between major API versions. -- -- Tools like cabal-install take these preferences into account when -- constructing install plans. -- base < 4 parsec < 3 cabal-install < 0.10 Try installing it with --constraint="base >= 4" and if that doesn't suffice, --preference="base >= 4". Cheers, Daniel

On Monday 27 September 2010 13:44:07, Christian Maeder wrote:

The HTTP.cabal file is not correct!   Build-depends: base >= 2 && < 4, network, parsec, mtl

(an additional constraint does not help)

Cheers Christian

In that case, change the local .cabal file as an immediate measure and notify the maintainer.

Am 27.09.2010 14:06, schrieb Christian Maeder:

...

The HTTP.cabal file is not correct! Build-depends: base >= 2 && < 4, network, parsec, mtl

Changing "< 4" to "< 5" works for the HTTP package (which is buggy anyway http://hackage.haskell.org/trac/ghc/ticket/4251).

But adjusting cabal-install.cabal is not enough.

It works with the darcs version http://darcs.haskell.org/cabal-install/ Oddly, the Cabal version displayed is: cabal-install version 0.9.2 using version 1.9.2 of the Cabal library although ghc-7 comes with Cabal-1.10.0.0 C. diff -rN old-cabal-install//cabal-install.cabal new-cabal-install//cabal-install.cabal 87c87 < Cabal >= 1.9 && < 1.10, ---

Cabal >= 1.9 && < 1.11,

92c92 < time >= 1.1 && < 1.2 ---

time >= 1.1 && < 1.3

99c99 < directory >= 1 && < 1.1, ---

directory >= 1 && < 1.2,

102c102 < containers >= 0.1 && < 0.4, ---

containers >= 0.1 && < 0.5,

Am 27.09.2010 15:12, schrieb Christian Maeder:

I wasn't able to compile yet. After 4 minutes it failed with:

Context reduction stack overflow; size = 46

and I'm increasing the context-stack further.

It goes through with -fcontext-stack=100, but the compilation time is unacceptable. 55 minutes for the following two files on x86_64: [381 of 536] Compiling Logic.Comorphism ( Logic/Comorphism.hs, Logic/Comorphism.o ) [382 of 536] Compiling Logic.Modification ( Logic/Modification.hs, Logic/Modification.o ) And the second one isn't finished yet. C.

Maybe this is related to: http://hackage.haskell.org/trac/ghc/ticket/816

(ghc-6.10.x or ghc-6.12.x have no such problems.)

Cheers Christian

Am 27.09.2010 16:38, schrieb Simon Peyton-Jones:

We found another occurrence of very poor performance in a smaller program. We have a nice fix; but won't be able to commit for a few days

Let's hope it fixes your problem too!

Ok, I'll hang on. Cheers Christian (Btw compiling module Logic.Modification failed after 2 hours with such a large error message, that I could not scroll back to the top.)

Simon

| -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Christian Maeder | Sent: 27 September 2010 15:32 | Cc: glasgow-haskell-users@haskell.org | Subject: Re: context-stack GHC 7.0.1 Release Candidate 1 | | Am 27.09.2010 15:12, schrieb Christian Maeder: | > I wasn't able to compile yet. After 4 minutes it failed with: | > | > Context reduction stack overflow; size = 46 | > | > and I'm increasing the context-stack further. | | It goes through with -fcontext-stack=100, but the compilation time is | unacceptable. 55 minutes for the following two files on x86_64: | | [381 of 536] Compiling Logic.Comorphism ( Logic/Comorphism.hs, | Logic/Comorphism.o ) | [382 of 536] Compiling Logic.Modification ( Logic/Modification.hs, | Logic/Modification.o ) | | And the second one isn't finished yet. | | C. | > | > Maybe this is related to: | > http://hackage.haskell.org/trac/ghc/ticket/816 | > | > (ghc-6.10.x or ghc-6.12.x have no such problems.) | > | > Cheers Christian | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Am 08.10.2010 18:52, schrieb Simon Peyton-Jones:

Christian

We've committed a wave of patches that should substantially improve the typechecker. Could you try with the current HEAD?

I've tried with http://www.haskell.org/ghc/dist/current/dist/ghc-7.1.20101010-x86_64-unknown... and it became worse. With -fcontext-stack=200 [368 of 519] Compiling Logic.Comorphism ( Logic/Comorphism.hs, Logic/Comorphism.o ) did not go through within 109 minutes: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 27743 maeder 20 0 316m 280m 17m R 100 1.7 109:27.22 ghc Does this version contain the patches? (I'm currently compiling the HEAD, unless you tell me, that it won't help) Please don't release a compiler that can no longer compile our sources. Cheers Christian

(Or you can wait for the next release candidate, end next week; but sooner is better.)

Simon

| -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell- | users-bounces@haskell.org] On Behalf Of Christian Maeder | Sent: 27 September 2010 15:32 | Cc: glasgow-haskell-users@haskell.org | Subject: Re: context-stack GHC 7.0.1 Release Candidate 1 | | Am 27.09.2010 15:12, schrieb Christian Maeder: | > I wasn't able to compile yet. After 4 minutes it failed with: | > | > Context reduction stack overflow; size = 46 | > | > and I'm increasing the context-stack further. | | It goes through with -fcontext-stack=100, but the compilation time is | unacceptable. 55 minutes for the following two files on x86_64: | | [381 of 536] Compiling Logic.Comorphism ( Logic/Comorphism.hs, | Logic/Comorphism.o ) | [382 of 536] Compiling Logic.Modification ( Logic/Modification.hs, | Logic/Modification.o ) | | And the second one isn't finished yet. | | C. | > | > Maybe this is related to: | > http://hackage.haskell.org/trac/ghc/ticket/816 | > | > (ghc-6.10.x or ghc-6.12.x have no such problems.) | > | > Cheers Christian | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

I was running into a similar issue and haven't noticed a dramatic improvement with the latest changes. The number of ticks taken to compile are approximately the same before and after the latest patch. However the system still compiles just fine with a context stack of 200. Which is OK by me. The system I'm working with uses functional dependencies and type families w/ type equalities. Could I improve the performance of my system by replacing the functional dependencies with type families & type equalities? The part of the system that uses functional dependencies is monad-param: http://hackage.haskell.org/package/monad-param http://hackage.haskell.org/package/monad-paramThe other part of the system I can't release the source to yet. :-\ I know, not very useful. -Corey O'Connor coreyoconnor@gmail.com http://www.coreyoconnor.com On Tue, Oct 19, 2010 at 8:57 AM, Simon Peyton-Jones wrote:

Christian

Dimitrios and I (mainly D) have fixed this. Your system compiles nicely now. Can you try again with the HEAD?

Simon

| -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto: glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Christian Maeder | Sent: 12 October 2010 12:47 | To: Simon Peyton-Jones | Cc: glasgow-haskell-users@haskell.org | Subject: Re: context-stack GHC 7.0.1 Release Candidate 1 | | Am 08.10.2010 18:52, schrieb Simon Peyton-Jones: | > Christian | > | > We've committed a wave of patches that should substantially improve the | typechecker. Could you try with the current HEAD? | | I've tried with | http://www.haskell.org/ghc/dist/current/dist/ghc-7.1.20101010-x86_64-unknown... | linux.tar.bz2 | | and it became worse. With -fcontext-stack=200 | | [368 of 519] Compiling Logic.Comorphism ( Logic/Comorphism.hs, | Logic/Comorphism.o ) | | did not go through within 109 minutes: | | PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND | | 27743 maeder 20 0 316m 280m 17m R 100 1.7 109:27.22 ghc | | | Does this version contain the patches? | | (I'm currently compiling the HEAD, unless you tell me, that it won't help) | | Please don't release a compiler that can no longer compile our sources. | | Cheers Christian | | > (Or you can wait for the next release candidate, end next week; but sooner is | better.) | > | > Simon | > | > | -----Original Message----- | > | From: glasgow-haskell-users-bounces@haskell.org [mailto: glasgow-haskell- | > | users-bounces@haskell.org] On Behalf Of Christian Maeder | > | Sent: 27 September 2010 15:32 | > | Cc: glasgow-haskell-users@haskell.org | > | Subject: Re: context-stack GHC 7.0.1 Release Candidate 1 | > | | > | Am 27.09.2010 15:12, schrieb Christian Maeder: | > | > I wasn't able to compile yet. After 4 minutes it failed with: | > | > | > | > Context reduction stack overflow; size = 46 | > | > | > | > and I'm increasing the context-stack further. | > | | > | It goes through with -fcontext-stack=100, but the compilation time is | > | unacceptable. 55 minutes for the following two files on x86_64: | > | | > | [381 of 536] Compiling Logic.Comorphism ( Logic/Comorphism.hs, | > | Logic/Comorphism.o ) | > | [382 of 536] Compiling Logic.Modification ( Logic/Modification.hs, | > | Logic/Modification.o ) | > | | > | And the second one isn't finished yet. | > | | > | C. | > | > | > | > Maybe this is related to: | > | > http://hackage.haskell.org/trac/ghc/ticket/816 | > | > | > | > (ghc-6.10.x or ghc-6.12.x have no such problems.) | > | > | > | > Cheers Christian | > | _______________________________________________ | > | 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

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Am 19.10.2010 17:57, schrieb Simon Peyton-Jones:

Christian

Dimitrios and I (mainly D) have fixed this. Your system compiles nicely now. Can you try again with the HEAD?

I've just checked with http://www.haskell.org/ghc/dist/current/dist/ghc-7.1.20101024-x86_64-unknown... and hets compiles fine after setting -fcontext-stack=100. (I did not try smaller values yet.) Thanks a lot Christian

Simon

| -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Christian Maeder | Sent: 12 October 2010 12:47 | To: Simon Peyton-Jones | Cc: glasgow-haskell-users@haskell.org | Subject: Re: context-stack GHC 7.0.1 Release Candidate 1 | | Am 08.10.2010 18:52, schrieb Simon Peyton-Jones: | > Christian | > | > We've committed a wave of patches that should substantially improve the | typechecker. Could you try with the current HEAD? | | I've tried with | http://www.haskell.org/ghc/dist/current/dist/ghc-7.1.20101010-x86_64-unknown... | linux.tar.bz2 | | and it became worse. With -fcontext-stack=200 | | [368 of 519] Compiling Logic.Comorphism ( Logic/Comorphism.hs, | Logic/Comorphism.o ) | | did not go through within 109 minutes: | | PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND | | 27743 maeder 20 0 316m 280m 17m R 100 1.7 109:27.22 ghc | | | Does this version contain the patches? | | (I'm currently compiling the HEAD, unless you tell me, that it won't help) | | Please don't release a compiler that can no longer compile our sources. | | Cheers Christian | | > (Or you can wait for the next release candidate, end next week; but sooner is | better.) | > | > Simon | > | > | -----Original Message----- | > | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell- | > | users-bounces@haskell.org] On Behalf Of Christian Maeder | > | Sent: 27 September 2010 15:32 | > | Cc: glasgow-haskell-users@haskell.org | > | Subject: Re: context-stack GHC 7.0.1 Release Candidate 1 | > | | > | Am 27.09.2010 15:12, schrieb Christian Maeder: | > | > I wasn't able to compile yet. After 4 minutes it failed with: | > | > | > | > Context reduction stack overflow; size = 46 | > | > | > | > and I'm increasing the context-stack further. | > | | > | It goes through with -fcontext-stack=100, but the compilation time is | > | unacceptable. 55 minutes for the following two files on x86_64: | > | | > | [381 of 536] Compiling Logic.Comorphism ( Logic/Comorphism.hs, | > | Logic/Comorphism.o ) | > | [382 of 536] Compiling Logic.Modification ( Logic/Modification.hs, | > | Logic/Modification.o ) | > | | > | And the second one isn't finished yet. | > | | > | C. | > | > | > | > Maybe this is related to: | > | > http://hackage.haskell.org/trac/ghc/ticket/816 | > | > | > | > (ghc-6.10.x or ghc-6.12.x have no such problems.) | > | > | > | > Cheers Christian | > | _______________________________________________ | > | 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

On 27/09/10 12:19, Ganesh Sittampalam wrote:

On Sun, 26 Sep 2010, Ian Lynagh wrote:

...

We are pleased to announce the first release candidate for GHC 7.0.1:

http://new-www.haskell.org/ghc/dist/7.0.1-rc1/

This includes the source tarball, installers for OS X and Windows, and bindists for amd64/Linux and i386/Linux.

Please test as much as possible; bugs are much cheaper if we find them before the release!

ganesh@nevis:~/dataenc$ cabal install regex-posix Resolving dependencies... Configuring regex-posix-0.94.4... Preprocessing library regex-posix-0.94.4... Building regex-posix-0.94.4... [1 of 6] Compiling Text.Regex.Posix.Wrap ( dist/build/Text/Regex/Posix/Wrap.hs, dist/build/Text/Regex/Posix/Wrap.o ) SpecConstr Function `lvl_s2xM{v} [lid]' has three call patterns, but the limit is 0 Use -fspec-constr-count=n to set the bound Use -dppr-debug to see specialisations ghc: panic! (the 'impossible' happened) (GHC version 7.0.0.20100924 for x86_64-unknown-linux): initC: srt_lbl

Let me know if you'd prefer this to be recorded in trac or would like me to try to cut it down.

Thanks - someone else already reported this one: http://hackage.haskell.org/trac/ghc/ticket/4345 Cheers, Simon

Cheers,

Ganesh

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

On Mon, Sep 27, 2010 at 11:55:51AM -0700, Evan Laforge wrote:

There are some issues with the .pkg installer under OS X:

Installers shouldn't be deleting the old version!

This has been a long-standing bug of the OS X installer. We'd love a fix from an OS X installer expert! The framework-pkg target in distrib/MacOS/Makefile is how we build the installer.

solution for this is to have /usr/bin/ghc-a.b.c point to .../GHC.framework/Versions/abc/... instead of ../GHC.framework/Versions/Current/...

Yes, that would make sense, if we could install multiple versions simultaneously. Thanks Ian

On Wed, Sep 29, 2010 at 04:56:18PM -0700, Evan Laforge wrote:

On Tue, Sep 28, 2010 at 8:18 AM, Ian Lynagh wrote:

...

On Mon, Sep 27, 2010 at 11:55:51AM -0700, Evan Laforge wrote:

...

There are some issues with the .pkg installer under OS X:

Installers shouldn't be deleting the old version!

This has been a long-standing bug of the OS X installer. We'd love a fix from an OS X installer expert! The framework-pkg target in distrib/MacOS/Makefile is how we build the installer.

...

solution for this is to have /usr/bin/ghc-a.b.c point to .../GHC.framework/Versions/abc/... instead of ../GHC.framework/Versions/Current/...

Yes, that would make sense, if we could install multiple versions simultaneously.

I'm far from an OS X installer expert, but after some puttering and trial and error I came up with a patch that seems to work.

Great, thanks!

I created http://hackage.haskell.org/trac/ghc/ticket/4354 and attached the patch.

We now have a mixture of org.haskell.ghc and org.haskell.GHC Is that deliberate, or should I lowercase them all?

The main question is whether or not I can kill Uninstaller, as it's even more broken now than it was before. If yes, I'll attach another patch that removes it.

I'd prefer to fix it, if possible. Is there anything magic about the name, or could we have Uninstaller-7.0.1 etc? Thanks Ian

On Mon, Oct 18, 2010 at 02:37:04PM -0700, Evan Laforge wrote:

I don't think there's anything magic about the name. The tricky thing about uninstallation is detecting when you uninstalled the currently "active" version (as defined by the plain 'ghc' symlinks and thy Current symlink), and either remove the links in that case, or pick the highest remaining version and relink it.

I've pushed patches to do this, and also added the full GHC version and arch (i386/x86_64) to the framework version number. One annoyance is that if you have 7.1.20101023-i386 installed, then 7.1.20101022-i386 won't actually install any files (Console's log gave something to the effect of "newer version already installed" as the reason). I'm not sure if that can be fixed by fiddling with CURRENT_PROJECT_VERSION, or by fixing/removing the version number in GHC-relocatable.pmdoc/01ghc.xml or GHC-system.pmdoc/01ghc.xml.

WRT stuff like versioned man pages, I'm also reluctant to diverge from what the standard unix install does. How does it handle multiple versions and uninstalls?

By installing different versions in different directories. There are some versioned programs etc, but we aren't consistent about it. We probably should be, one way or the other. Thanks Ian

On Sat, Oct 23, 2010 at 04:21:29PM -0700, Evan Laforge wrote:

...

I've pushed patches to do this, and also added the full GHC version and arch (i386/x86_64) to the framework version number.

One annoyance is that if you have 7.1.20101023-i386 installed, then 7.1.20101022-i386 won't actually install any files (Console's log gave something to the effect of "newer version already installed" as the reason). I'm not sure if that can be fixed by fiddling with CURRENT_PROJECT_VERSION, or by fixing/removing the version number in GHC-relocatable.pmdoc/01ghc.xml or GHC-system.pmdoc/01ghc.xml.

I couldn't find any documentation for how OS X determines a newer version,

I'm not sure either, so at some point we might have an upgrade that it thinks is a downgrade (e.g. 7.8 -> 7.10). But actually, we want it to just install what we ask it to, without checking for "newer" versions already being installed.

You can install with the cmdline installer, which will print those errors to stdout, but the GUI version annoyingly won't tell you if it aborted because it thinks you have a newer version.

Right; you can find the message ("open /Applications/Utilities/Console" and select "All Events", from memory), but yes, it is annoying that it looks like it has successfully installed, and you need to go looking for the log.

I'll download the latest build and mess around with it some more to try to figure out what makes version upgrades happen.

Great, thanks!

The main thing to verify is that release versions with different patchlevels upgrade properly, since this is certainly something people will be doing.

With 7.1.20101022-i386 installed I can install 7.1.20101023-i386 without 7.1.20101022-i386 being uninstalled, so hopefully it'll work. Thanks Ian

On Tue, Sep 28, 2010 at 11:46:19AM +1000, Jens Petersen wrote:

...

We are pleased to announce the first release candidate for GHC 7.0.1

Thank you! :)

Are you going to bootstrap the testsuite? I would like to run it but having trouble working out how to do that.

Ah, sorry, I tarred up the wrong thing. Try this instead: http://new-www.haskell.org/ghc/dist/7.0.1-rc1/testsuite-7.0.0.20100924-2.tar... Thanks Ian

On Tuesday 28 September 2010 11:10:58 pm David Fox wrote:

I'm seeing errors like this in various places, which I guess are coming from the new type checker:

Data/Array/Vector/Prim/BUArr.hs:663:3: Couldn't match type `s' with `s3' because this skolem type variable would escape: `s3' This skolem is bound by the polymorphic type `forall s. ST s a' The following variables have types that mention s fill0 :: MBUArr s e -> ST s Int (bound at Data/Array/Vector/Prim/BUArr.hs:669:5) In the first argument of `runST', namely `(do { marr <- newMBU n; n' <- fill0 marr; unsafeFreezeMBU marr n' })'

I would love to hear an explanation about what they mean and what to do about them. (This one is from uvector.)

This appears to be due to MonoLocalBinds. The issue boils down to: foo = runST (bar 5) where bar x = return x The necessary type for bar is forall s. n -> ST s n n being bound in the type of foo (or, feel free to make it concrete). However, GHC will not infer this when the non-generalizing let is turned on. But, no rigid s will do, because it's expected to be a quantified variable by runST. As for why this happens in uvector: -fglasgow-exts is one of the ghc-options in the cabal file. Alternately, a type signature could be given. -- Dan

On Tue, Sep 28, 2010 at 8:36 PM, Antoine Latter wrote:

On Tue, Sep 28, 2010 at 10:10 PM, David Fox wrote:

...

I'm seeing errors like this in various places, which I guess are coming from the new type checker:

Data/Array/Vector/Prim/BUArr.hs:663:3:     Couldn't match type `s' with `s3'       because this skolem type variable would escape: `s3'     This skolem is bound by the polymorphic type `forall s. ST s a'     The following variables have types that mention s       fill0 :: MBUArr s e -> ST s Int         (bound at Data/Array/Vector/Prim/BUArr.hs:669:5)     In the first argument of `runST', namely       `(do { marr <- newMBU n;              n' <- fill0 marr;              unsafeFreezeMBU marr n' })'

GHC no longer generalizes local bindings - which means that while previously the 'where' defined function would have had a type:

...

fill0 :: forall s .  ... -> ST s Int

Where the elipsis indicates an unspecified portion of the local type signature.

I would recommend writing a type signature, but that requires writing a type signature for it's helper function:

...

fill s i = ...

Except I don't know how to write a type signature for this.

The value 's' passed in is bound by pattern matching on this guy's constructor:

data Stream a = forall s. Stream (s -> Step s a) !s Int

in the top-level function, so I don't even know if it has a type I can name.

I'll try to boil this down to something I can put on hpaste.

Antoine

I have to say, as an everyday joe programmer, that the obscurity of this message disturbs me. I hope I don't see it very often.

| Except I don't know how to write a type signature for this. | | The value 's' passed in is bound by pattern matching on this guy's constructor: | | data Stream a = forall s. Stream (s -> Step s a) !s Int | | in the top-level function, so I don't even know if it has a type I can name. You can bind the type variable using a pattern type signature case x of Stream fun (state :: s) n -> ... This should bind the type variable 's'. Simon

I've been meaning to write a blog post about this, because it's a significant change. I'll do this when I get home after ICFP. Briefly though: * If you use -XGADTs or -XTypeFamilies (or -fglasgow-exts, which is deprecated) you get -XMonoLocalBinds, which says that local let/where bindings are not auto-generalised. There's an extensive discussion of the reason for this decision in our paper "Let should not be generalised" and the journal version http://haskell.org/haskellwiki/Simonpj/Talk:OutsideIn * One of the main times this matters is in situations like foo = runST (bar 5) where bar x = return x Here 'bar' must have a polymorphic type, in order to be mentioned in runST's argument * The error message does point out that 'bar' is a possible culprit. In David's example: The following variables have types that mention s fill0 :: MBUArr s e -> ST s Int * The solution is usually to add a type signature for the offending variable (fillO in this case); you can still have polymorphic bindings in let/where, but they need a type signature. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of David Fox | Sent: 29 September 2010 04:11 | To: glasgow-haskell-users@haskell.org | Subject: Re: ANNOUNCE: GHC 7.0.1 Release Candidate 1 | | I'm seeing errors like this in various places, which I guess are | coming from the new type checker: | | Data/Array/Vector/Prim/BUArr.hs:663:3: |     Couldn't match type `s' with `s3' |       because this skolem type variable would escape: `s3' |     This skolem is bound by the polymorphic type `forall s. ST s a' |     The following variables have types that mention s |       fill0 :: MBUArr s e -> ST s Int |         (bound at Data/Array/Vector/Prim/BUArr.hs:669:5) |     In the first argument of `runST', namely |       `(do { marr <- newMBU n; |              n' <- fill0 marr; |              unsafeFreezeMBU marr n' })' | | I would love to hear an explanation about what they mean and what to | do about them. (This one is from uvector.) | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Thanks. I have written a blog post to describe the generalisation question and describe how to adapt your code http://hackage.haskell.org/trac/ghc/blog/LetGeneralisationInGhc7 I've added the link to Don's GHC7 page. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Don Stewart | Sent: 29 September 2010 14:53 | To: Simon Peyton-Jones | Cc: glasgow-haskell-users@haskell.org | Subject: Re: ANNOUNCE: GHC 7.0.1 Release Candidate 1 | | I've created a wiki page to track the common errors when upgrading to | GHC 7. | | http://haskell.org/haskellwiki/Upgrading_packages/Updating_to_GHC_7 | | Solutions to each problem should be listed here. | | simonpj: | > I've been meaning to write a blog post about this, because it's a significant change. | I'll do this when I get home after ICFP. Briefly though: | > | > * If you use -XGADTs or -XTypeFamilies (or -fglasgow-exts, which is deprecated) | you get -XMonoLocalBinds, which says that local let/where bindings are not auto- | generalised. There's an extensive discussion of the reason for this decision in our | paper "Let should not be generalised" and the journal version | http://haskell.org/haskellwiki/Simonpj/Talk:OutsideIn | > | > * One of the main times this matters is in situations like | > foo = runST (bar 5) | > where bar x = return x | > Here 'bar' must have a polymorphic type, in order to be mentioned in runST's | argument | > | > * The error message does point out that 'bar' is a possible culprit. In David's | example: | > The following variables have types that mention s | > fill0 :: MBUArr s e -> ST s Int | > | > * The solution is usually to add a type signature for the offending variable (fillO in | this case); you can still have polymorphic bindings in let/where, but they need a type | signature. | > | > Simon | > | > | -----Original Message----- | > | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | > | bounces@haskell.org] On Behalf Of David Fox | > | Sent: 29 September 2010 04:11 | > | To: glasgow-haskell-users@haskell.org | > | Subject: Re: ANNOUNCE: GHC 7.0.1 Release Candidate 1 | > | | > | I'm seeing errors like this in various places, which I guess are | > | coming from the new type checker: | > | | > | Data/Array/Vector/Prim/BUArr.hs:663:3: | > |     Couldn't match type `s' with `s3' | > |       because this skolem type variable would escape: `s3' | > |     This skolem is bound by the polymorphic type `forall s. ST s a' | > |     The following variables have types that mention s | > |       fill0 :: MBUArr s e -> ST s Int | > |         (bound at Data/Array/Vector/Prim/BUArr.hs:669:5) | > |     In the first argument of `runST', namely | > |       `(do { marr <- newMBU n; | > |              n' <- fill0 marr; | > |              unsafeFreezeMBU marr n' })' | > | | > | I would love to hear an explanation about what they mean and what to | > | do about them. (This one is from uvector.) | > | _______________________________________________ | > | 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 | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

On Wednesday 29 September 2010 16:51:35, Antoine Latter wrote:

Here's a boiled-down equivalent to what the issue is in uvector:

http://hpaste.org/40213/doesnt_work_in_ghc_7

In GHC 6.12, this would have type-checked. In GHC 7, I need to add a type-signature to the 'helper' function, except I 'm not sure how to do it.

So the function in uvector might need a larger refactoring.

Antoine

It works if you define helper inside the runST via a let (no type signature). I suspect that would become a larger refactoring in uvector, but at least there's a simple way.