- Glasgow-haskell-users

Strangeness in the syntax of types
by Niklas Broberg 23 Jun '09

23 Jun '09

Hi all, I've had a curious bug report [1] for haskell-src-exts, pointing to a difference in behavior between haskell-src-exts and GHC. Digging further, it seems to me like GHC is behaving quite strange in this instance, but since we don't have formal documentation for the extensions I can't be sure. I'm *almost* convinced this is a bug in GHC, but with these type extensions I can never be quite sure. Thus I'm putting it out here in the hope that someone will either explain why it is this way, or tell me to go file a bug report. The gist of it is the following piece of code: > multipleCtx :: Eq a => Show a => a > multipleCtx = undefined GHC accepts this code, while haskell-src-exts requires parentheses around the latter part of the signature, i.e. Eq a => (Show a => a). The difference is the following productions haskell-src-exts: > ctype :: { PType } > : 'forall' ktyvars '.' ctype > | context '=>' type > | type GHC: > ctypedoc :: { LHsType RdrName } > : 'forall' tv_bndrs '.' ctypedoc > | context '=>' ctypedoc > | gentypedoc Notice GHC's recursive call to ctypedoc after the =>. I have no idea what the doc suffix on the production is intended to indicate though - and I was curious to find a separate set of rules that don't have that suffix: > ctype :: { LHsType RdrName } > : 'forall' tv_bndrs '.' ctype > | context '=>' type > | type This one looks just like the one that haskell-src-exts uses - type instead of ctype after the =>. So what's the difference between the two in GHC? Looking further, the former is used in top-level type signatures, while the latter is used for pretty much everything else. In particular, you can't put a ctypedoc inside parentheses, there you would have to use ctype. So while GHC accepts the above definition, it rejects e.g. the (seemingly) equivalent > multipleCtx :: (Eq a => Show a => a) > multipleCtx = undefined My guess would be that there's a bug here, and that it's the recursive call to ctypedoc that is at fault, it should really be gentypedoc. On the other hand there's no problem parsing either, so there's no technical reason not to allow chained contexts without parentheses, even though I personally think it looks quite awkward. Enough rambling - can someone make me the wiser? Cheers, /Niklas [1] http://trac.haskell.org/haskell-src-exts/ticket/37

3 3

Re: was 6.10.3 prerelease
by Christian Maeder 22 Jun '09

22 Jun '09

Maybe a binary distribution for Mac OS Tiger would be useful. (I prefer the plain .tar.gz files over .pkg, because they don't require root rights.) I usually make them using a file mk/build.mk containing: BIN_DIST=1 Project=Ghc HADDOCK_DOCS = YES #XMLDocWays = html using the commands: ./configure make make binary-dist I can offer binary dists for x68 under Solaris and PPC Mac OS 10.5 (Leopard), the latter depending on: /opt/local/lib/libiconv.2.dylib /opt/local/lib/libncurses.5.dylib /opt/local/lib/libgmp.3.dylib Cheers Christian http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/het… http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/het… Yusaku Hashimoto wrote: > It is problem about the library for dealing OS process. This bug is > fixed, and fixed version of process is in the repository. You can check > out latest library from http://darcs.haskell.org/packages/process and > replace the library in the build directory (libraries/process). > > If you are bothered to this, you can just comment-in a line 90 (maybe > near of here...) in libraries/process/cbits/runProcess.c to > disableItimers() in the child process. > > HTH, > Hashimoto > > On 2009/06/20, at 21:09, Iain Barnett wrote: > >> In reference to http://www.nabble.com/6.10.3-prerelease-td23346957.html >> >> I also run Mac OSX 10.4.11 (there are some left) and I experience the >> same problem but with the full release of 6.10.3 from source. I've >> read the discussion and the trac ticket at >> http://hackage.haskell.org/trac/ghc/ticket/3243, but I have no idea >> how to actually get and apply the patch. >> >> Sorry if I'm being incredibly thick, (or even just a bit thick) but I >> have barely used C or darcs (though I do have darcs installed). Any >> advice on how to fix this is much appreciated - originally I just >> wanted to upgrade Cabal but when it didn't work I tried to upgrade >> GHC, and now I seem to be digging a big hole! >> >> Iain >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users(a)haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

was 6.10.3 prerelease
by Iain Barnett 20 Jun '09

20 Jun '09

In reference to http://www.nabble.com/6.10.3-prerelease-td23346957.html I also run Mac OSX 10.4.11 (there are some left) and I experience the same problem but with the full release of 6.10.3 from source. I've read the discussion and the trac ticket at http:// hackage.haskell.org/trac/ghc/ticket/3243, but I have no idea how to actually get and apply the patch. Sorry if I'm being incredibly thick, (or even just a bit thick) but I have barely used C or darcs (though I do have darcs installed). Any advice on how to fix this is much appreciated - originally I just wanted to upgrade Cabal but when it didn't work I tried to upgrade GHC, and now I seem to be digging a big hole! Iain

1 0

build question: ghc 6.11.20090605 -> ghc 6.10.3?
by Uwe Hollerbach 19 Jun '09

19 Jun '09

Hi, all, is it expected that a snapshot version (I'm using 2009.06.05) should be able to build the released version 6.10.3? This weekend I tried the "porting to an unsupported machine" procedure with the aforementioned snapshot version; that worked, after some fussing, and I seem to have a working ghc install, including several libraries and cabal. But I tried building the Haskell Platform, and it warns (rightly, as it turns out) about this being an unsupported version of ghc. So I'd like to get onto the regular release train, as it were, and transfer myself to ghc 6.10.3. But that fails to build, after a while. Specifically, it goes until it's trying to compile the stage1 version of ghc/Main.hs, and then it complains that it can't find the file "../includes/ghcautoconf.h". Now, that file does exist; but it looks like it's being referenced from HsVersions.h, which lives in the lib/ tree of the installed snapshot compiler, and relative to the location of that file, there is indeed no such path. Is that a bug? If I create the includes directory where HsVersions.h appears to be seeking it, and add in ghcautoconf.h from where it got created during the setup of ghc 6.10.3, the build proceeds (a little) further, but it still dies. thanks... Uwe PS I suppose I should describe in a little bit of detail what I did for the porting, might be useful for someone else trying this. It was a rather vanilla port, x86_64-unknown-linux to same; my target machine is my workstation at work, where I don't have root, and I do have permission from IT to install this stuff, but no support... so they won't install rpms for me, or anything like that. It's also a slightly old and somewhat customized version of some RedHat corporate release, so recent plain-vanilla tarballs didn't work... hence the need to port. So: first problem was that my target machine identified itself as x86_64-unknown-linux-gnu; note the 4-part identifier, rather than the 3-part that's more usual. That confused the configure scripts... I had to hack up configure.ac to force it to see itself as x86_64-unknown-linux. First problem solved... After that, the back-and-forth of the various derived files was tedious but straightforward, and stuff built well. The second problem was that the command listed on the ghc porting page, "for c in libraries/*/configure; ...", is specific to bash or sh, and my workstation runs tcsh. No problem, I knew what to do, but it might be an issue for someone who doesn't know. The third issue was the sed syntax on the same page: the version of sed that I was using didn't like the space between the "-i" and the ".bak". I don't know if that's a variation from one version of sed to another, or a typo on the page, or??? Again no big deal, the error message from sed was informative enough for me to figure out what to do. The fourth issue was that the "make all_ghc_stage2" command failed: the linker complained that it couldn't find the hs_main symbol. I found that in RtsMain.o, and manually added that object file to the appropriate (?) library; then it worked. I'm not actually sure that I got the actually-most-correct library, but... it didn't seem to break anything. After that, it went through ok. I checked that that stage2 compiler could indeed build a working executable from haskell sources, that was ok, and then I rebuilt that snapshot from scratch using that compiler. That worked fine, and after that the various libraries needed to get cabal up and running were straightforward.

2 1

GADT record syntax and contexts
by Philip K.F. Hölzenspies 19 Jun '09

19 Jun '09

Dear GHCers, Maybe this question is more for Haskell-cafe, but since it involves language extensions as provided by GHC, it seems reasonable to post it here. The GHC user guide lists under 7.4 [1] the extensions to data types and type synonyms. My question involves 7.4.5 (although the overlap with 7.4.6 is considerable; maybe the two should be merged). A property of GADTs that I really appreciate is the fact that constructor contexts are made available by pattern matching (I don't quite understand why normal ADTs could do this, btw, but that's another question). The problem I have now, though, is that there doesn't seem to be a syntax to combine contexts and records in GADTs. Consider this program: data ContTest a where A :: Show a => a -> ContTest a data RecTest a where B { arg :: a } :: RecTest a data RecContTest a where C { showable :: Show a => a } :: RecContTest a a :: ContTest a -> String a (A a) = show a b :: Show a => RecTest a -> String b = show . arg c :: RecContTest a -> String c (C { showable = x }) = show x Both ContTest and RecTest work swimmingly (with functions a and b, respectively). However, GHC complains that it can not deduce Show for type a in function c. My definition of RecContTest is the only syntactical form I could come up with that GHC accepts. Is there a syntax for what I want here? Regards, Philip PS. As a side-note. In section 7.4.5, the manual states that: "At the moment, record updates are not yet possible with GADT-style declarations, so support is limited to record construction, selection and pattern matching." However, if I add: update org@(B {}) x = org { arg = x } and evaluate "b $ update (B True) False" the response is "False" as one would expect. Is this line in the user guide outdated, or is support for updates unstable or partial? [1]http://www.haskell.org/ghc/docs/latest/html/users_guide/data-type-extensi…

6 6

--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