- Glasgow-haskell-users

--out-implib when linking shared libraries
by Neil Mitchell 17 Jun '09

17 Jun '09

Hi, I've just built a Haskell dll on Windows. As part of the process it generated an 14Mb foo.dll, and a 40Mb foo.dll.a. Looking at the flags passed to ld I see --out-implib=foo.dll.a. What is the purpose of the .a file? What might it be needed for? Is it possible to suppress it? I could easily be building 100 of these things and 4Gb of disk for unused files is a little painful. Thanks Neil

3 5

Re: GADT record syntax and contexts
by John Lato 17 Jun '09

17 Jun '09

>From the perspective of someone who doesn't use GADT's much, I find (B) to be more clear. John Lato > SPJ wrote: > > Question for everyone: > > * are (A) and (B) the only choices? > * do you agree (B) is best >

1 0

can't run Grapefruit
by Dean Herington 16 Jun '09

16 Jun '09

I'm trying to give Grapefruit a try. I installed it as described in section 4.1 of http://www.haskell.org/haskellwiki/Grapefruit. When I tried to run the Simple.hs example, I got the problem shown below. Any ideas? My machine is running Windows XP Pro 2002 SP3. TIA Dean GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Prelude> :m + Graphics.UI.Grapefruit.Circuit Prelude Graphics.UI.Grapefruit.Circuit> :m + Graphics.UI.Grapefruit.GTK Prelude Graphics.UI.Grapefruit.Circuit Graphics.UI.Grapefruit.GTK> :m + Examples.Grapefruit.Simple Prelude Graphics.UI.Grapefruit.Circuit Graphics.UI.Grapefruit.GTK Examples.Grapefruit.Simple> run GTK mainCircuit Loading package syb ... linking ... done. Loading package base-3.0.3.0 ... linking ... done. Loading package array-0.2.0.0 ... linking ... done. Loading package containers-0.2.0.0 ... linking ... done. Loading package bytestring-0.9.1.4 ... linking ... done. Loading package old-locale-1.0.0.1 ... linking ... done. Loading package old-time-1.0.0.1 ... linking ... done. Loading package random-1.0.0.1 ... linking ... done. Loading package Win32-2.2.0.0 ... linking ... done. Loading package filepath-1.1.0.1 ... linking ... done. Loading package directory-1.0.0.2 ... linking ... done. Loading package process-1.0.1.0 ... linking ... done. Loading package haskell98 ... linking ... done. Loading package mtl-1.1.0.2 ... linking ... done. Loading package glib-0.10.0 ... can't load .so/.DLL for: intl (addDLL: could not load DLL)

4 4

Help debugging a deadlock in salvia on GHC 6.10 i386
by Corey O'Connor 15 Jun '09

15 Jun '09

I'm working on trimming down the test code and filing a real bug. I'm going to list out what I know right now and if anything jumps out please let me know. Thanks! I'm running a webserver built using salvia [1] and GHC 6.10 [2]. I've trimmed down the code enough such that there is no obvious source of a deadlock in either salvia or the reset of the web server. I don't have any specific conditions that reproduce the issue as well. Just after some time, anywhere from a few minutes to a few hours, the server deadlocks. No particular request or number of requests seem to trigger the deadlock. 1) Salvia accepts connections on the main thread then forkIOs a new thread to actually handle the request. The new thread uses Handle based IO. 2) As I understand it, there are issues with forkProcess and Handle based IO. While this is a web server I'm avoiding using "daemonize" code that relies on forkProcess. no forkProcess is occurring that I know of. 3) The thread state summary printed by calling printAllThreads() from GDB is: all threads: threads on capability 0: other threads: thread 2 @ 0xb7d66000 is blocked on an MVar @ 0xb7d670b4 thread 3 @ 0xb7d74214 is blocked on an MVar @ 0xb7da88f0 4) The thread states according to a "thread apply all bt" from GDB is: 1. GDB backtrace Thread 4 (Thread 0xb7cffb90 (LWP 30891)): #0 0xb8080416 in __kernel_vsyscall () #1 0xb7fd0075 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x083f4320 in waitCondition (pCond=0x9a7cc1c, pMut=0x9a7cc4c) at posix/OSThreads.c:65 #3 0x0840de64 in yieldCapability (pCap=0xb7cff36c, task=0x9a7cc00) at Capability.c:506 #4 0x083eb292 in schedule (initialCapability=0x8565aa0, task=0x9a7cc00) at Schedule.c:293 #5 0x083ed5ff in workerStart (task=0x9a7cc00) at Schedule.c:1923 #6 0xb7fcc50f in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #7 0xb7f49a0e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 3 (Thread 0xb74feb90 (LWP 30892)): #0 0xb8080416 in __kernel_vsyscall () #1 0xb7fd0075 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x083f4320 in waitCondition (pCond=0x9a7ef3c, pMut=0x9a7ef6c) at posix/OSThreads.c:65 #3 0x0840de64 in yieldCapability (pCap=0xb74fe36c, task=0x9a7ef20) at Capability.c:506 #4 0x083eb292 in schedule (initialCapability=0x8565aa0, task=0x9a7ef20) at Schedule.c:293 #5 0x083ed5ff in workerStart (task=0x9a7ef20) at Schedule.c:1923 #6 0xb7fcc50f in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #7 0xb7f49a0e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 2 (Thread 0xb6cfdb90 (LWP 30916)): #0 0xb8080416 in __kernel_vsyscall () #1 0xb7fd0075 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x083f4320 in waitCondition (pCond=0x9a7e12c, pMut=0x9a7e15c) at posix/OSThreads.c:65 #3 0x0840de64 in yieldCapability (pCap=0xb6cfd36c, task=0x9a7e110) at Capability.c:506 #4 0x083eb292 in schedule (initialCapability=0x8565aa0, task=0x9a7e110) at Schedule.c:293 #5 0x083ed5ff in workerStart (task=0x9a7e110) at Schedule.c:1923 #6 0xb7fcc50f in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #7 0xb7f49a0e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 1 (Thread 0xb7e666b0 (LWP 30890)): #0 0xb8080416 in __kernel_vsyscall () #1 0xb7fd0075 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x083f4320 in waitCondition (pCond=0x9a7cb3c, pMut=0x9a7cb6c) at posix/OSThreads.c:65 #3 0x0840de64 in yieldCapability (pCap=0xbfa822ac, task=0x9a7cb20) at Capability.c:506 #4 0x083eb292 in schedule (initialCapability=0x8565aa0, task=0x9a7cb20) at Schedule.c:293 #5 0x083ed463 in scheduleWaitThread (tso=0xb7d80800, ret=0x0, cap=0x8565aa0) at Schedule.c:1895 #6 0x083e851a in rts_evalLazyIO (cap=0x8565aa0, p=0x8489478, ret=0x0) at RtsAPI.c:517 #7 0x083e79d5 in real_main () at Main.c:111 Anybody think of anything so far? Cheers, Corey O'Connor

2 2

Fwd: Unification for rank-N types
by Vladimir Reshetnikov 12 Jun '09

12 Jun '09

Forwarding to GH list. ---------- Forwarded message ---------- From: Vladimir Reshetnikov <v.reshetnikov(a)gmail.com> Date: Tue, 9 Jun 2009 16:51:59 +0500 Subject: Re: Unification for rank-N types To: haskell-cafe <haskell-cafe(a)haskell.org> One more example: This does not type-check: ------------------------------------------------------- {-# LANGUAGE RankNTypes, ImpredicativeTypes #-} f :: [forall a. t a -> t a] -> t b -> t b f = foldr (.) id ------------------------------------------------------- Couldn't match expected type `forall a. f a -> f a' against inferred type `b -> c' In the first argument of `foldr', namely `(.)' But this, very similar, does type-check: ------------------------------------------------------- {-# LANGUAGE RankNTypes, ImpredicativeTypes #-} f :: [forall a. t a -> t a] -> t b -> t b f = foldr (\g -> (.) g) id ------------------------------------------------------- What is the reason for this? Thanks, Vladimir On 6/9/09, Vladimir Reshetnikov <v.reshetnikov(a)gmail.com> wrote: > Hi, > > I have the following code: > ------------------------------------------------------- > {-# LANGUAGE RankNTypes #-} > > f :: ((forall a. a -> a) -> b) -> b > f x = x id > > g :: (forall c. Eq c => [c] -> [c]) -> ([Bool],[Int]) > g y = (y [True], y [1]) > > h :: ([Bool],[Int]) > h = f g > ------------------------------------------------------- > > GHC rejects it: > Couldn't match expected type `forall a. a -> a' > against inferred type `forall c. (Eq c) => [c] -> [c]' > Expected type: forall a. a -> a > Inferred type: forall c. (Eq c) => [c] -> [c] > In the first argument of `f', namely `g' > In the expression: f g > > But, intuitively, this code is type-safe, and actually I can convince > the typechecker in it with the following workaround: > ------------------------------------------------------- > h :: ([Bool],[Int]) > h = let g' = (\(x :: forall a. a -> a) -> g x) in f g' > ------------------------------------------------------- > > So, is the current behavior of GHC correct ot it is a bug? > How unification for rank-N types should proceed? > > Thanks, > Vladimir >

2 1

FlexibleContexts and FlexibleInstances
by Niklas Broberg 11 Jun '09

11 Jun '09

Dear all, This post is partly a gripe about how poor the formal documentation for various GHC extensions is, partly a gripe about how GHC blurs the lines between syntactic and type-level issues as well as between various extensions, and partly a gripe about how the Haskell 98 report is sometimes similarly blurred where syntax is concerned (or not). All these things make the life of a poor parser implementor quite miserable at times. All in good jest of course, but with an edge of truth, especially regarding (lack of) formal documentation. The issue at hand which has caused my frustration is the FlexibleContexts [1] and FlexibleInstances [2] extensions, which lift restrictions imposed by Haskell 98 on the forms of contexts and instances that may be defined. Great extensions both of them - but what do they do, really really? The following toy program requires MultiParamTypeClasses OR FlexibleContexts in order to be accepted by GHC(i): > f :: (T a b) => a -> Int > f _ = 0 This of course assumes that we import the definition of T, we *must* have MultiParamTypeClasses enabled if we want to declare T. Both extensions thus enable classes with more than one argument to appear in contexts. Changing the program to > f :: (T a ()) => a -> Int > f _ = 0 i.e. changing the second argument to T to () instead, means we now *must* have FlexibleInstances, in order to allow the non-tyvar argument. This is nothing surprising, this is what FlexibleInstances are supposed to do. But the question is, is this a syntactic issue or a typing issue? In GHC proper this doesn't really matter much, as long as it is caught *somewhere* then all is dandy. GHC's parser lets everything pass, and it's the type checker that balks at this program. But for someone like me with *only* a parser, this is a question that needs a clear answer. Looking at the online report, the productions regarding contexts are context -> class | ( class1 , ... , classn ) (n>=0) class -> qtycls tyvar | qtycls ( tyvar atype1 ... atypen ) (n>=1) qtycls -> [ modid . ] tycls tycls -> conid tyvar -> varid Ok, so clearly the () is a syntactic extension enabled by FlexibleContexts, as it is not a tyvar nor a tyvar applied to a sequence of types. So this is something that a parser should handle. FlexibleContexts also enables similar parses of contexts in other places, for instance in class declarations, for which the Haskell 98 report says topdecl -> class [scontext =>] tycls tyvar [where cdecls] scontext -> simpleclass | ( simpleclass1 , ... , simpleclassn ) (n>=0) simpleclass -> qtycls tyvar The difference here is that the simpleclass doesn't allow the tyvar applied to a sequence of types bit. FlexibleContexts lifts that restriction too, so there should be no difference between the two kinds of contexts. So the new formal productions for flexible contexts should be something like fcontext -> fclass | ( fclass1 , ... , fclassn ) (n>=0) fclass -> qtycls type1 ... typen (n>=1) topdecl -> data [fcontext =>] simpletype = constrs [deriving] | newtype [fcontext =>] simpletype = newconstr [deriving] | class [fcontext =>] tycls tyvar [where cdecls] | instance [fcontext =>] qtycls inst [where idecls] gendecl -> vars :: [fcontext =>] type Does this seem correct? Now let's turn to FlexibleInstances, which similarly lifts restrictions, only to instance declarations instead of contexts. The Haskell 98 report says on instance declarations: topdecl -> instance [scontext =>] qtycls inst [where idecls] inst -> gtycon | ( gtycon tyvar1 ... tyvark ) (k>=0, tyvars distinct) | ( tyvar1 , ... , tyvark ) (k>=2, tyvars distinct) | [ tyvar ] | ( tyvar1 -> tyvar2 ) (tyvar1 and tyvar2 distinct) Note the re-appearance of scontext, which is the same as above. The instance head must be a type constructor, possibly applied to a number of type variables, or one of three built-in syntactic cases. This is where I consider the Haskell 98 report blurry - the fact that the tyvars must be distinct, is that truly a syntactic issue? It might be, it's certainly something that could be checked syntactically. But when you take into account that with the proper extensions, they no longer need to be distinct, at what level would we expect such a check to happen? My gut feeling is that this check for distinctness is something that a type checker might do better than a parser, though it's not clear cut by any means. But since I don't do any other kind of name resolution or checking in my parser even if it would be possible (e.g. multiple declarations of the same symbol), I would find it a bit anomalous to check this too. Turning on FlexibleInstances, we shouldn't need to follow any of the above restrictions on inst. In other words, the flexible production should simply be something like finst -> type Right? Now, FlexibleInstances *also* lifts the restriction on contexts, just like FlexibleContexts - but *only* for the contexts of instance declarations. This may seem like a reasonable thing, but it certainly gives me some headaches. It means I could not treat the contexts uniformly, but would need to have separate syntactic categories (or rather post-parse checks) that look different between instance contexts and other contexts (including class). So with FlexibleInstances on, there are *three* different kinds of contexts allowed: scontext for class declaration, fcontext for instance declarations, and context for all other uses of contexts (type signatures, data/newtype declarations). Just a small headache, since I already apparently needed two categories from Haskell 98, but still. I'm not sure I find it reasonable, that flexible instances are enabled just for instance declarations but not elsewhere, but I'm sure a lot of thought was given to that. If it was up to *me* though, I would leave the flexible contexts with FlexibleContexts entirely, which means you would have to use both flags if you wanted both in your instance declarations. Would that be a bad thing? Separation of concern seems desirable to me (and no, I'm not saying that just because it would be easier to implement in the parser)... At any rate, to make a long rant short: * Are my interpretations of the lifted restrictions by FlexibleContexts and FlexibleInstances correct? * Is it reasonable that the issue of checking that tyvars are distinct should not be considered syntactic? * Would it also be reasonable to make the separation of concern between FlexibleContexts and FlexibleInstances more clean? Thanks for reading, and please give me input! Cheers, /Niklas [1] http://www.haskell.org/ghc/docs/latest/html/users_guide/other-type-extensio… [2] http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class-extensio…

4 6

List comprehensions and impredicative rank-N types
by Vladimir Reshetnikov 11 Jun '09

11 Jun '09

Hi, Consider the following definitions: ----------------------------------------------------------- {-# LANGUAGE RankNTypes, ImpredicativeTypes #-} foo :: [forall a. [a] -> [a]] foo = [reverse] bar :: [a -> b] -> a -> b bar fs = head fs ----------------------------------------------------------- According to the Haskell Report, [f | f <- foo] translates to (let ok f = [f]; ok _ = [] in concatMap ok foo), right? So, I wonder why (bar [f | f <- foo]) typechecks, but (bar (let ok f = [f]; ok _ = [] in concatMap ok foo)) and (bar foo) do not typecheck? Thanks, Vladimir

1 0

Re: [darcs-users] dropping GHC 6.6 support
by Isaac Dupree 11 Jun '09

11 Jun '09

[redirecting to ghc-users also] Matthias Kilian wrote: >> (Which as I understood would make porting a newer ghc to OpenBSD easier). > > Yes. The only alternatives would be to provide precompiled binaries > (which is ugly, imho) or to maintain several versions of ghc in the > ports tree (which is a maintainance nightmare). .hc files are ugly too; IMO about as ugly as precompiled binaries (.hc are platform specific and practically unreadable, just like binaries). At least the GHC HQ think so: currently bootstrapping-from-HC only works unregisterised (so it will be slow. Also, inherently, won't ever use GHC's NCG :-) (native code generator) ) -Isaac

1 0

6.10.4 plans
by Ian Lynagh 09 Jun '09

09 Jun '09

Hi all, Unfortunately, since the release of 6.10.3, still more problems have come to light in the 6.10 branch. We are therefore planning to do a 6.10.4 release. For 6.10.4, we will only consider fixes for serious bugs that cannot be easily worked around. So far, we plan to look into: * One of the patches in 6.10.2 introduced a problem where mkWeakForeignEnv# could segfault (already fixed) * readMutVar# is inlined/duplicated http://hackage.haskell.org/trac/ghc/ticket/3207 (already fixed, patch waiting to be merged) * "Permission denied" errors on Windows: http://hackage.haskell.org/trac/ghc/ticket/3231 http://hackage.haskell.org/trac/ghc/ticket/2924 * Some ghci tests fail with hLookAhead errors. We would like to at least understand exactly what is going on here. If you find any other bugs that you think we should look into for 6.10.4, please let us know. We don't have any plans for when to do the release yet, but we would like to be confident that we have waited long enough for any other bugs to surface, and to have time for 6.10.4 to be well-tested. Thanks Ian

3 4

is the library iconv necessary for haskeline?
by Christian Maeder 08 Jun '09

08 Jun '09

Hi, building ghc-6.10.3 under x86 solaris eventually failed with: Configuring ghc-bin-6.10.3... cabal-bin: At least the following dependencies are missing: haskeline -any gmake[3]: *** [boot.stage.2] Error 1 I think, haskeline is not build because libiconv is missing: -bash-3.00$ ./Setup configure --prefix=/NONEXISTENT --bindir=/NONEXISTENT --libdir=/NONEXISTENT --libexecdir=/NONEXISTENT --datadir=/NONEXISTENT --docdir=/NONEXISTENT --haddockdir=/NONEXISTENT --htmldir=/NONEXISTENT --with-compiler=/export/local1/home/maeder/haskell/ghc-6.10.3/ghc/stage1-inplace/ghc --with-hc-pkg=/export/local1/home/maeder/haskell/ghc-6.10.3/utils/ghc-pkg/install-inplace/bin/ghc-pkg --libsubdir=$pkgid --with-gcc=gcc --with-ld=/usr/ccs/bin/ld --with-alex=/home/pub-bkb/bin/alex --with-happy=/home/pub-bkb/bin/happy --configure-option='--with-cc=gcc --with-hsc2hs=/export/local1/home/maeder/haskell/ghc-6.10.3/utils/hsc2hs/install-inplace/bin/hsc2hs --haddock-options=--use-contents=../index.html --use-index=../doc-index.html' --enable-library-profiling --enable-split-objs Configuring haskeline-0.6.1.5... checking whether to use -liconv... Setup: Unable to link against the iconv library. I wonder how this check for -liconv is generated. I have a file /usr/include/iconv.h but not file /usr/lib/libiconv.* Under Linux I've installed successfully http://www.haskell.org/ghc/dist/6.10.3/ghc-6.10.3-i386-unknown-linux-n.tar.… and I was able to install http://hackage.haskell.org/packages/archive/haskeline/0.6.1.6/haskeline-0.6… without libiconv! > ./Setup configure Configuring haskeline-0.6.1.6... checking whether to use -liconv... not needed. However, the mere existence of /usr/local/lib/libiconv* files causes configure to use -liconv: checking whether to use -liconv... using -liconv. I would like to avoid this (unnecessary?) dependency (without removing /usr/local/lib). (/usr/local/lib is _not_ part of LD_LIBRARY_PATH and should not be searched by gcc, but is still somehow found and used.) Are there any configure options that work? (The cabal-flag libiconv is false.) How is "checking whether to use ..." generated? Is libiconv really necessary under Solaris? Cheers Christian

2 2