- Glasgow-haskell-users

ANNOUNCE: GHC 7.0.1 Release Candidate 1
by Ian Lynagh 25 Oct '10

25 Oct '10

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! Thanks Ian, on behalf of the GHC team

15 43

GHC static binaries with glibc-2.12?
by Alexander Dunlap 24 Oct '10

24 Oct '10

Hi all, I recently upgraded my Arch Linux system to glibc 2.12 and static binaries compiled with GHC 6.12.3 all fail with the message "mkTextEncoding: invalid argument (Invalid argument)". This did not happen with glibc 2.11. Has anyone else had this problem? Does anyone have any advice for debugging it? Thanks, Alex

4 6

Re: clearing GHCi (and, by extension, hint) loaded module dependencies
by Alex Suraci 24 Oct '10

24 Oct '10

On Tue, Sep 21, 2010 at 10:30 AM, Daniel Gorín <jcpetruzza(a)gmail.com> wrote: > Hi > > What I make of this is that you should run a new interpreter (i.e. use runInterpreter(T)) instead of calling reset. > > Could you try this this approach and see if it works? > > Daniel Every "load:" call already runs its own interpreter. I guess the session is sticking around somewhere in-between. I've been playing around with hint and the GHC API trying to figure this one out (with Simon's tips in mind), but haven't found a way to discard the session, or even on what level that should be done. In runInterpreter? Or in separate runGhc calls? The best guess I have so far is using getSession/setSession inside the interpreter call to restore it to the way it was before, but that seems to have no effect. Here's what I'm using to test: http://hpaste.org/40015/hintghc_memory Even with setSession, the cache seems to be sticking around - subsequent loads are faster, and the memory usage doesn't go down. -- Alex

3 7

ghc-6.12.3 package base - build failure on ubuntu10.10 (works with 10.4)
by Mischa Dieterle 19 Oct '10

19 Oct '10

Hi, I'm getting a build failure when I try to compile ghc-6.12 from the http://darcs.haskell.org/ghc-6.12 repo. ---- ghc-cabal: Missing dependency on a foreign library: * Missing C library: iconv This problem can usually be solved by installing the system package that provides this library (you may need the "-dev" version). If the library is already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where it is. make[1]: *** [libraries/base/dist-install/package-data.mk] Error 1 make: *** [all] Error 2 ---- I'm using a ubuntu 10.10-64 bit system with libc-bin and libc-dev-bin installed. I don't think the problem is a missing iconv library. Maybe the problem is in the generated configure script by the new autoconf version (autoconf version is 2.67). Maybe someone can help. Cheers, Mischa Stderr output of ./configure on base module is: ./configure: line 8709: ${ac_cv_search_iconv_t_cd_ ______________________cd___iconv_open_____ ______________________iconv_cd_NULL_NULL_NULL_NULL__ ______________________iconv_close_cd__+set}: bad substitution ./configure: line 8735: ac_cv_search_iconv_t_cd_: command not found ./configure: line 8736: ______________________cd___iconv_open_____: command not found ./configure: line 8737: ______________________iconv_cd_NULL_NULL_NULL_NULL__: command not found ./configure: line 8742: ${ac_cv_search_iconv_t_cd_ ______________________cd___iconv_open_____ ______________________iconv_cd_NULL_NULL_NULL_NULL__ ______________________iconv_close_cd__+set}: bad substitution ./configure: line 8742: ${ac_cv_search_iconv_t_cd_ ______________________cd___iconv_open_____ ______________________iconv_cd_NULL_NULL_NULL_NULL__ ______________________iconv_close_cd__+set}: bad substitution ./configure: line 8746: ${ac_cv_search_iconv_t_cd_ ______________________cd___iconv_open_____ ______________________iconv_cd_NULL_NULL_NULL_NULL__ ______________________iconv_close_cd__+set}: bad substitution ./configure: line 8746: ac_cv_search_iconv_t_cd_: command not found ./configure: line 8747: ______________________cd___iconv_open_____: command not found ./configure: line 8748: ______________________iconv_cd_NULL_NULL_NULL_NULL__: command not found ./configure: line 8751: ______________________cd___iconv_open_____: command not found

3 3

Has something about -prof -auto-all changed in GHC 7?
by Bryan O'Sullivan 19 Oct '10

19 Oct '10

I've been trying to use a library compiled with profiling in 7.0.1rc1, where I'm compiling the library with -auto-all, but I'm getting output when I run an app linked against the library that contains almost no information from inside the library: basically just a single cost centre from the app itself shows up, and almost nothing inside the library. I've verified via "cabal build -v" that the library is indeed being built with -prof -auto-all.

3 3

Template Haskell: onward and upward
by Simon Peyton-Jones 19 Oct '10

19 Oct '10

Folks Following lots of feedback from users, especially at ICFP, I've evolved some proposals for Template Haskell, that should make it both more expressive, and more secure. http://hackage.haskell.org/trac/ghc/blog/Template%20Haskell%20Proposal Do let me know what you think. Discussion by email is fine (cc me if it's on Haskell-cafe), or comments direct on the Trac. (None of this will be in GHC 7.0; it's a proposed plan for post-release improvements.) Thanks Simon

1 0

Re: ANNOUNCE: GHC 7.0.1 Release Candidate 1
by Vivian McPhail 17 Oct '10

17 Oct '10

Trying to build rc1 from source linux x86_64 BuildFlavour = perf It seems that the -fPIC flag is set, but an error still occurs ( /usr/bin/ld: libraries/integer-gmp/gmp/objs/abs.o: relocation R_X86_64_32 against `.text' can not be used when making a shared object; recompile with -fPIC ) "inplace/bin/ghc-stage1" -fPIC -dynamic -O -H64m -package-name base-4.3.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/autogen -Ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build/autogen -Ilibraries/base/include -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist-install/build/autogen/cabal_macros.h -package ghc-prim-0.2.0.0 -package integer-gmp-0.2.0.2 -package rts-1.0 -package-name base -XMagicHash -XExistentialQuantification -XRank2Types -XScopedTypeVariables -XUnboxedTuples -XForeignFunctionInterface -XUnliftedFFITypes -XDeriveDataTypeable -XGeneralizedNewtypeDeriving -XFlexibleInstances -XStandaloneDeriving -XPatternGuards -XEmptyDataDecls -XNoImplicitPrelude -XCPP -no-user-package-conf -rtsopts -O2 -XGenerics -fno-warn-deprecated-flags -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -c libraries/base/./Data/Typeable.hs-boot -o libraries/base/dist-install/build/Data/Typeable.dyn_o-boot /usr/bin/ld: libraries/integer-gmp/gmp/objs/abs.o: relocation R_X86_64_32 against `.text' can not be used when making a shared object; recompile with -fPIC libraries/integer-gmp/gmp/objs/abs.o: could not read symbols: Bad value collect2: ld returned 1 exit status make[1]: *** [libraries/integer-gmp/dist-install/build/ libHSinteger-gmp-0.2.0.2-ghc7.0.0.20100924.so] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [all] Error 2 Vivian

5 4

un-used record wildcards
by Serge D. Mechveliani 17 Oct '10

17 Oct '10

Dear GHC developers, I use the language extension of RecordWildcards, for example, f (Foo {foo1 = n, foo2 = m, ..}) = ... But the complier warns about un-used values of foo3, foo4, probably, due to the extension of Foo {foo1 = n, foo2 = m, foo3 = foo3, foo4 = foo4}. In such cases, these warnings look as unneeded. Is it possible to have an un-used binding warnings with exception for wildcards in records? If not, then has it sense to introduce an option? Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

4 5

Re: Local evidence and type class instances
by Max Bolingbroke 17 Oct '10

17 Oct '10

HI Antoine, I didn't know UHC already had this - thanks for the pointer! It seems they have read about implicit configurations too, as the example they use is very similar to the paper. In fact, they also have another extension to the concept that I was intentionally avoiding mentioning - they ensure that the lexically most closely bound instance is used to satisfy a demand for a type class operation. This means that you can sensibly have local instances that overlap global ones. I'm not sure how I feel about this feature, though I certainly see the motivation. On 16 October 2010 15:47, Antoine Latter <aslatter(a)gmail.com> wrote: > Substituting f for f' in this example will change the meaning of the > operation significantly, which is, in my mind, hard to explain and > reason about. That's the behaviour I had in mind. There is no doubt that local instances are a big complexity increase, but IMHO this behaviour is relatively easy to reason about as long as you know about the dictionary passing translation. Indeed, it's practically mandatory to use dictionary-passing to implement this behaviour. Local instances would probably never get added to a compiler (like JHC) that doesn't use that technique. RE your later point: > Along similar lines as my last post, would I be able to write the > following type signature: > > myFunct :: Ord Int => Int -> (...) > > and have it always use the local instance for Ord Int? Is this the > type that the type checker would infer for my function? To my mind, if you have that signature, then myFunct would use whatever Ord Int instance was available at the use site of myFunct (i.e. wherever it was mentioned syntactically). It is certainly interesting to note that adding a context like this might be useful if you were using local instances. Cheers, Max

2 1

Fwd: Local evidence and type class instances
by Antoine Latter 16 Oct '10

16 Oct '10

Forwarding to list. ---------- Forwarded message ---------- From: Antoine Latter <aslatter(a)gmail.com> Date: Sat, Oct 16, 2010 at 9:47 AM Subject: Re: Local evidence and type class instances To: Max Bolingbroke <batterseapower(a)hotmail.com> On Sat, Oct 16, 2010 at 7:11 AM, Max Bolingbroke <batterseapower(a)hotmail.com> wrote: > 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 > """ I think UHC has something like that: http://www.cs.uu.nl/wiki/bin/view/Ehc/UhcUserDocumentation#3_8_Local_instan… One thing that worries me is that the local instance only applies to type-expressions that consume constraints - if the constraint was satisfied before the local constraint was introduced then the local constraint would not apply. Am I making sense? I don't have much of a background in type-theory, so I may not be using the correct language, but I'm having trouble seeing how it wouldn't be confusing. What I'm thinking is that the following two functions would have different effect: f n = Set.insert n and: f' (n::Int) = Set.insert n When called like so: updateSet (n::Int) s = let n' = someComputation n s in f n' s where instance Ord s ... Substituting f for f' in this example will change the meaning of the operation significantly, which is, in my mind, hard to explain and reason about. Type-classes are engineered to be global in scope. It's nice that from a GHC type-checking perspective they need not be, but changing them to be non-global is also an engineering and design problem. Antoine > > 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 > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >

1 0