November 2010 - Glasgow-haskell-users

MonoLocalBinds and darcs
by Sittampalam, Ganesh 04 Nov '10

04 Nov '10

Hi, I've just been updating darcs 2.5 for GHC 7.0. I had to add about 40 signatures for MonoLocalBinds in about 140 files/30K LOC. Is that about normal? darcs does make fairly heavy use of rank 2 polymorphism which leads to quite a lot of local definitions needing to be polymorphic. Also, NoMonoLocalBinds didn't help at all, which surprised me a bit - I thought it might at least make some of the signatures unnecessary. Finally, is NoMonoLocalBinds supposed to imply NPlusKPatterns? The only changes I was able to revert when I enabled it were a couple of those! Cheers, Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===============================================================================

6 7

Re: [Haskell-cafe] change in overlapping instance behavior between GHC 6.12 and GHC 7 causes compilation failure
by David Fox 04 Nov '10

04 Nov '10

I would love to know the answer to this. On Tue, Nov 2, 2010 at 3:36 PM, Jeremy Shaw <jeremy(a)n-heptane.com> wrote: > Hello, > > I have a module, XMLGenerator, which has some overlapping instances. > I have a second module, Test, which imports that module and also adds > some more overlapping instances. > > Both modules contain {-# LANGUAGE OverlappingInstances #-} at the top. > > Under some old version of 6.13 (and probably 6.12), if I put both > modules in the same directory and try to load Test.hs, it gets the > error: > > Test.hs:16:15: > Overlapping instances for EmbedAsChild (M IO) (XMLGenT m (XML m)) > arising from a use of `asChild' at Test.hs:16:15-21 > Matching instances: > instance (m1 ~ m, EmbedAsChild m c) => > EmbedAsChild m (XMLGenT m1 c) > -- Defined at XMLGenerator.hs:16:10-68 > instance (XML m ~ x, XMLGen m) => EmbedAsChild m x > -- Defined at XMLGenerator.hs:19:10-51 > In the first argument of `($)', namely `asChild' > In the expression: asChild $ (genElement "foo") > In the definition of `asChild': > asChild b = asChild $ (genElement "foo") > > If I put the XMLGenerator module in a separate package, dummy-hsx, and > the Test modules links against it, I still get the error. > > *but* if I add: > > Extensions: OverlappingInstances > > to the dummy-hsx.cabal file, then Test.hs compiles just fine! So, for > starters, I do not understand why that happens. > > Under GHC 7.0rc1, modifying the .cabal file has no effect. Instead I > always get the error: > > Test.hs:16:15: > Overlapping instances for EmbedAsChild (M IO) (XMLGenT m (XML m)) > arising from a use of `asChild' > Matching instances: > instance [overlap ok] (m1 ~ m, EmbedAsChild m c) => > EmbedAsChild m (XMLGenT m1 c) > -- Defined in XMLGenerator > (The choice depends on the instantiation of `m' > To pick the first instance above, use -XIncoherentInstances > when compiling the other instance declarations) > > Adding the IncoherentInstances flag does make it compile -- but I have > never enabled that flag and not regretted it. > > What changed between GHC 6.12 and GHC 7.0? Is there a some solution > besides using IncoherentInstances in every module that imports > XMLGenerator? > > I have attached XMLGenerator.hs, Test.hs, and dummy-hsx.cabal. > > thanks! > - jeremy > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > >

1 0

Fixing LDAP lib compilation on OpenBSD
by Julien Dessaux 03 Nov '10

03 Nov '10

Hi GHC folks, I'm using the LDAP lib for one of my projects and I found a problem while building it on an OpenBSD system. It wouldn't compile because there is a macro named differently in the ldap.h include file. Under linux, this macro is named LDAP_X_PROXY_AUTHZ_FAILURE but on OpenBSD (and probably other BSD flavours), it's named LDAP_PROXY_AUTHZ_FAILURE. I attached the diff I wrote in order to compile the lib on OpenBSD, but it's not a patch I can submit cause it now won't compile on Linux. How can I amend this in order to have a code that would compile on both systems? How is it possible to specify such conditional system dependent stuff for a C binding? Thanks in advance for your help, -- Julien Dessaux

2 3

generating C stubs with GHC API
by Victor Nazarov 03 Nov '10

03 Nov '10

I would like to get access to functions exported from Haskell module and to generate custom stubs for them using GHC API. As I understand, I need to obtain a list of ForeignDecl's (data structure defined in HsDecls GHC module) for given source module. How to achieve this with GHC API? -- Victor Nazarov

1 0

link problem under macosx
by Christian Maeder 03 Nov '10

03 Nov '10

Hi, after installing http://lambda.galois.com/hp-tmp/2010.2.0.0/haskell-platform-2010.2.0.0.i386… and various more libraries using cabal, we get the following linker error below. A simple hello program compiles and links fine and uses /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) as shown by "otool -L". Does someone have an explanation or solution? Cheers Christian Linking dist/build/hets/hets ... Undefined symbols: "_iconv_close", referenced from: _hs_iconv_close in libHSbase-4.2.0.2.a(iconv.o) "_iconv_open", referenced from: _hs_iconv_open in libHSbase-4.2.0.2.a(iconv.o) "_iconv", referenced from: _hs_iconv in libHSbase-4.2.0.2.a(iconv.o) ld: symbol(s) not found collect2: ld returned 1 exit status

3 4

making 7.01-pre
by Serge D. Mechveliani 02 Nov '10

02 Nov '10

Dear GHC developers, I am testing this fresh ghc-7.0.0.20101028 on Debian Linux, i386-family. Making it from source by ghc-6.12.3 is all right. Then, making it from source by itself reports (here I abbreviate the messages by inserting `...') --------------------------------------------------------------------- + test -f mk/config.mk.old + cp -p mk/config.mk mk/config.mk.old ... ... "inplace/bin/mkdirhier" utils/ghc-cabal/dist/build/tmp//. "inplace/bin/mkdirhier" bootstrapping/. "/home/mechvel/ghc/7.01pre/inst1/bin/ghc" -H32m -O --make utils/ghc-cabal/ghc-cabal.hs -o utils/ghc-cabal/dist/build/tmp/ghc-cabal ... ... "rm" -f compiler/stage1/ghc_boot_platform.h Creating compiler/stage1/ghc_boot_platform.h... Done. "/usr/bin/gcc" -fno-stack-protector -DTABLES_NEXT_TO_CODE -Iincludes -Irts -DGEN_HASKELL -c includes/mkDerivedConstants.c -o includes/dist-ghcconstants/build/mkDerivedConstants.o ... ... ... utils/genprimopcode/dist/build/Lexer.o: In function `s2yT_info': (.text+0x1e1d): undefined reference to `__stginit_arrayzm0zi3zi0zi2_DataziArray_' ... ... utils/genprimopcode/dist/build/Parser.o: In function `s4pK_info': (.text+0x5691): undefined reference to `__stginit_arrayzm0zi3zi0zi2_DataziArray_' collect2: ld returned 1 exit status make[1]: *** [utils/genprimopcode/dist/build/tmp/genprimopcode] Error 1 make: *** [all] Error 2 --------------------------------------------------------------------- Why cannot it make itself? Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

4 4

Re: link problem under macosx
by John Lato 02 Nov '10

02 Nov '10

> > From: Christian Maeder <Christian.Maeder(a)dfki.de> > > Am 02.11.2010 11:48, schrieb Christian Maeder: > > Hi, > > > > after installing > > > http://lambda.galois.com/hp-tmp/2010.2.0.0/haskell-platform-2010.2.0.0.i386… > > and various more libraries using cabal, we get the following linker > > error below. > > > > A simple hello program compiles and links fine and uses > > /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version > > 7.0.0) as shown by "otool -L". > > > > Does someone have an explanation or solution? > > adding "-L/usr/lib" as first argument to ghc solved the problem. > Another cabal-package (gtk and friends) used /opt/local/lib under > library-dirs:. > > Are there better workarounds? > Judging from the /opt/*, it looks like you're using macports for gtk. The libiconv provided by macports is incompatible with the system libiconv, and trying to mix the two is a doomed effort. If you're using a gtk2hs from macports (or gtk+ from macports) it will link to /opt/local/lib/libiconv, but HP and ghc core libraries will link to /usr/lib/libiconv. This means that various haskell packages will be entirely incompatible with each other, and problems will manifest as these linker errors. Since Apple seems disinclined to fix the system's libiconv, and macports projects refuse to use it, the only real solution is to use either HP without macports or the macports GHC without HP. Personally I chose to use the HP and built gtk+ using http://gtk-osx.sourceforge.net/ , which is moderately painful but has been stable once it's built. John

2 1

Local evidence and type class instances
by Max Bolingbroke 02 Nov '10

02 Nov '10

Hi GHC users, Now that the Glorious New type checker can handle local evidence seamlessly, is it a big implementation burden to extend it to deal with local *type class instances* in addition to local *equality constraints*? For example, you could write this: """ f :: Bool f = id < id where instance Ord (a -> b) where _ `compare` _ = LT """ Not only would this prevent instances from "leaking" into all importing modules, but you could refer to *lexically scoped variables* in the type class instance. This would let programmers implement e.g. implicit configurations in the style of Kieslyov and Shan (http://okmij.org/ftp/Haskell/types.html#Prepose) without any mad hackery to tunnel pointers through the type system. Of course, it could lead to problems. For example: """ newtype MyInt = MyInt { unMyInt :: Int } f :: [Int] -> S.Set Int f xs = S.map unMyInt $ S.toList (map MyInt xs) where instance Ord MyInt where x `compare` y = unMyInt x `compare` unMyInt y g :: [Int] -> S.Set Int g xs = S.map unMyInt $ S.toList (map MyInt xs) where instance Ord MyInt where x `compare` y = unMyInt y `compare` unMyInt x main = do let s1 = f [1, 2] s2 = g [1, 2] print $ s1 == s2 -- prints False! print $ S.toList s1 == s2 -- prints True! """ I don't think this is a big problem. It would be up to the users of this extension to do the Right Thing. As Kieslyov and Shan point out, this extension also kills the principal types property - but so do GADTs. Just add more type signatures! Are there big theoretical problems with this extension, or is it just a lack of engineering effort that has prevented its implementation? Max

4 3

GHC.Types consturctors with #
by Larry Evans 01 Nov '10

01 Nov '10

http://www.haskell.org/ghc/docs/6.10.2/html/libraries/ghc-prim/GHC-Types.ht… contains: data Int = I# Int# What does I# Int# mean? I've tried a simple interpretation: Prelude GHC.Types> I# 5# <interactive>:1:5: parse error (possibly incorrect indentation) Prelude GHC.Types> but obviously that failed :( TIA. -Larry

3 2

Forall and type synonyms in GHC 7.0
by Mario Blažević 01 Nov '10

01 Nov '10

Before uploading a new version of my project on Hackage, I decided to future-proof it against GHC 7.0. I ran into several compile errors caused by the changes in let generalization, but these were easy to fix by adding extra type annotations. But then I ran into another problem that I can't fix so easily. Here is its trimmed-down reproduction: > {-# LANGUAGE RankNTypes #-} > > module Test where > > data Component c = Component {with :: c} > > pair1 :: (Bool -> c1 -> c2 -> c3) -> Component c1 -> Component c2 -> Component c3 > pair1 combinator (Component c1) (Component c2) = Component (combinator True c1 c2) > > type PairBinder m = forall x y r. (x -> y -> m r) -> m x -> m y -> m r > > pair2 :: Monad m => (PairBinder m -> c1 -> c2 -> c3) -> Component c1 -> Component c2 -> Component c3 > pair2 combinator = pair1 (combinator . chooseBinder) > > chooseBinder :: Monad m => Bool -> PairBinder m > chooseBinder right = if right then rightBinder else leftBinder > > leftBinder :: Monad m => PairBinder m > leftBinder f mx my = do {x <- mx; y <- my; f x y} > > rightBinder :: Monad m => PairBinder m > rightBinder f mx my = do {y <- my; x <- mx; f x y} The general idea here, if you're intrigued, is that pair1 belongs to a generic module that packages things it knows nothing about into Components. The remaining definitions belong to a client of the generic module, and pair2 is a specialization of pair1 to components that have something to do with monads. Now this little test compiles fine with GHC 6.12.1, but GHC 7.0.0.20101029 reports the following error in the pair2 definition: TestForall.lhs:13:42: Couldn't match expected type `forall x y r. (x -> y -> m r) -> m x -> m y -> m r' with actual type `(x -> y -> m1 r) -> m1 x -> m1 y -> m1 r' Expected type: Bool -> PairBinder m Actual type: Bool -> (x -> y -> m1 r) -> m1 x -> m1 y -> m1 r In the second argument of `(.)', namely `chooseBinder' In the first argument of `pair1', namely `(combinator . chooseBinder)' I've tried adding extra type annotations without making any progress. At this point I'm beginning to suspect I ran into a bug in GHC 7.0, but I can't find it in GHC Trac; the only ticket that looks similar is #4347, but that one works for me. Is this a bug? If not, how do I make my code compile?

2 2