November 2007 - Glasgow-haskell-users

Generalized newtype deriving 6.6 vs. 6.8
by Twan van Laarhoven 05 Nov '07

05 Nov '07

Hello, I noticed there is a difference in generalized newtype deriving between 6.6 and 6.8. In GHC 6.4.1 the following: > {-# LANGUAGE GeneralizedNewtypeDeriving #-} > > import Control.Monad.Error > > newtype MyMonad m a = MyMonad (m a) > deriving (Monad, MonadError String) correctly gives a derived instance MonadError String m => MonadError String (MyMonad m) The new GHC 6.8.1 complains with: No instance for (MonadError String m) arising from the 'deriving' clause of a data type declaration at DeriveTest.hs:(5,0)-(6,36) Possible fix: add an instance declaration for (MonadError String m) When deriving the instance for (MonadError String (MyMonad m)) Generalizing the instance to MonadError e m => MonadError e (MyMonad m) works in both versions. Twan

3 2

Help with Building on Mac OS X Leopard
by R Hayes 05 Nov '07

05 Nov '07

What resembles an old issue has reappeared when building HEAD on Leopard. The build of the stage two compiler fails with: ld: in /Users/rfh/3rdParty/builds/ghc-6.9.20071028/libraries/ haskell98/dist/build/libHShaskell98-1.0.1.a, archive has no table of contents This happens when the modify time on library is later than the timestamp on the library index. It's not an uncommon issue for building software on the Mac. The usual cause is builds that copy .a files and are unaware of this mac feature. Running ranlib on libHShaskell98-1.0.1.a file and resuming the make causes the build to continue until it gets to the next .a file. ld: in /Users/rfh/3rdParty/builds/ghc-6.9.20071028/libraries/array/ dist/build/libHSarray-0.1.a, archive has no table of contents It seems this problem has occurred before. My guess is that a work- around was put in place that no longer works on Leopard. I'm not sure exactly where to look in the Make system. Any pointers would be appreciated.

2 1

testing docon-2.11
by Serge D. Mechveliani 04 Nov '07

04 Nov '07

People, can anybody, please, test docon-2.11 ? It resides in http://www.botik.ru/pub/local/Mechveliani/docon/2.11-pre/ It needs to download, unzip, install and run the test according to install.txt, communicate to me the result (together with the GHC and system specification). It is for ghc-6.8.1 and ghc-6.6.1 (down-porting to 6.6.1 is by deleting " , containers" from docon.cabal). I have tested it in Debian Linux. It needs testing, for example, under MacOS. Thank you in advance for your help. ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

6.6.1 installlers
by Bulat Ziganshin 04 Nov '07

04 Nov '07

Hello glasgow-haskell-users, i've found that 6.6.1 downloading page ( http://haskell.org/ghc/download_ghc_661.html ) doesn't contain info about availability of Debian, Fedora and SUSE packages. is it possible to add it there? (also for other unices where such packages exist) the reason is that i distribute sources of my program and point users to this page for instructions on installing GHC. but it suggests to use generic linux package and don't tell anything about OS-specific packages. my users are not haskellers so they will be unable to find and install GHC package without knowing its exact name -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

2 1

Too many local registers...
by Cristian Perfumo 03 Nov '07

03 Nov '07

Hi, I did some modifications to GHC in order to read hardware counters. Many programs are compiled successfully, but with one of them, I have a problem: Too many local registers allocated by gcc at .../ghc-6.6.1-modified/driver/mangler/ghc-asm line 1602, <INASM> line 304643. It's ghc 6.6.1 on an Itanium processor. Some suggestion? Thanks in advance for an answer. Cristian

4 4

confusing GADT/scoped type variables behaviour
by Ganesh Sittampalam 02 Nov '07

02 Nov '07

Hi, I'm having some trouble writing code that uses GADTs. I finally got something that is portable between GHC 6.6 and 6.8, but I don't really understand what's going on, and I'm a bit unhappy with the number of type signatures required. I'll explain them with a series of cut-down examples below, so please forgive the gratuitous beta-redexes. My testing has been with GHC 6.6 and 6.8.0.20070921, but I believe from more limited testing that 6.6.1 behaves the same as 6.6. My first program works fine with both GHC 6.6 and 6.8: {-# OPTIONS_GHC -fglasgow-exts #-} module GADT where data C x y where C :: P x y -> C x x data P x y where P :: Q x y -> P x y data Q x y where Q :: Q x y data D x y where D :: C y z -> D x z f :: forall x y . D x y -> () f (D (C p)) | P q <- (\p -> p) p = case q of Q -> () {- end of program -} However, when I change it slightly to make the lambda expression inspect the structure of p: {-# OPTIONS_GHC -fglasgow-exts #-} module GADT where data C x y where C :: P x y -> C x x data P x y where P :: Q x y -> P x y data Q x y where Q :: Q x y data D x y where D :: C y z -> D x z f :: forall x y . D x y -> () f (D (C p)) | P q <- (\p@(P a) -> p) p = case q of Q -> () {- end of program -} it continues to work with 6.6, but 6.8 complains that q has a wobbly type and I should add a type annotation. So, I do so, also adding one to the original pattern for p otherwise my type variables aren't in scope: {-# OPTIONS_GHC -fglasgow-exts #-} module GADT where data C x y where C :: P x y -> C x x data P x y where P :: Q x y -> P x y data Q x y where Q :: Q x y data D x y where D :: C y z -> D x z f :: forall x y . D x y -> () f (D (C (p :: P w z))) | P q :: P w z <- (\p@(P a) -> p) p = case q of Q -> () {- end of program -} Fine with 6.8, but now 6.6 is unhappy. The type variable 'w' is actually the same as 'y', and 6.6 seems to have noticed this fact and says I should have given them the same name. So, I do so: {-# OPTIONS_GHC -fglasgow-exts #-} module GADT where data C x y where C :: P x y -> C x x data P x y where P :: Q x y -> P x y data Q x y where Q :: Q x y data D x y where D :: C y z -> D x z f :: forall x y . D x y -> () f (D (C (p :: P y z))) | P q :: P y z <- (\p@(P a) -> p) p = case q of Q -> () {- end of program -} Now 6.6 is happy. But 6.8 doesn't believe they are the same, and rejects it. I finally got it to work with both by removing the forall in the signature of f: {-# OPTIONS_GHC -fglasgow-exts #-} module GADT where data C x y where C :: P x y -> C x x data P x y where P :: Q x y -> P x y data Q x y where Q :: Q x y data D x y where D :: C y z -> D x z f :: D x y -> () f (D (C (p :: P y z))) | P q :: P y z <- (\p@(P a) -> p) p = case q of Q -> () {- end of program -} But, I don't really understand why this is so. I guess the 'y' in the outer signature is no longer a scoped type variable, so 6.6 doesn't complain, and is no longer the same as the inner 'y', so 6.8 doesn't complain, but it all feels a bit unsatisfactory. So, is there a good explanation of the errors from 6.8? Is 6.8 behaving as expected? Finally, ideally I'd like not to have any type signatures in the body of f - is this feasible with 6.8 like it was with 6.6? Cheers, Ganesh

3 2

Case of "Language" pragma - bug?
by Robin Bate Boerop 02 Nov '07

02 Nov '07

I'm using GHC 6.6.1. The manual says: "Pragmas all take the form {-# word ... #-} where word indicates the type of pragma, and is followed optionally by information specific to that type of pragma. Case is ignored in word." However, when I use "Language CPP" instead of "LANGUAGE CPP" in the pragma, the pragma is ignored. Is this a documentation bug? To test the problem, one can use "ghc --make testpragma1.hs" and "ghc --make testpragma2.hs" on the following: -- Robin Bate Boerop

7 7