December 2008 - Glasgow-haskell-users

type families and overlapping
by Jorge Marques Pelizzoni 17 Dec '08

17 Dec '08

Hi, While playing with type families in GHC 6.10.1, I guess I bumped into the no-overlap restriction. As I couldn't find any examples on that, I include the following (non-compiling) code so as to check with you if that's really the case: ------------------------------------------- {-# OPTIONS -fglasgow-exts #-} {-# LANGUAGE OverlappingInstances #-} {-# LANGUAGE UndecidableInstances #-} module Main where class Expr t where type ExprRslt t :: * eval :: t -> ExprRslt t instance Expr t where type ExprRslt t = t -- overlap? eval = id data Vector a = Vector {width :: !Int, dat :: [a]} data Subscript a = Subscript {vec :: (Vector a), ind :: !Int} instance Expr (Subscript a) where type ExprRslt (Subscript a) = a eval sub = (dat.vec $ sub) !! ind sub ------------------------------------------------ So this means that classes with associated types cannot have default instances at all? If so, could you possibly refer me to any material explaining why? Thanks in advance. Cheers, Jorge.

2 1

Type signature inside an instance declaration
by Kwanghoon Choi 16 Dec '08

16 Dec '08

======================================================================= module Test where class Arg a where pr :: a -> String instance Arg Int where pr _ = "i" instance Arg Char where pr _ = "c" instance Arg a => Arg [a] where pr _ = "[" ++ pr (undefined :: a) ++ "]" -- the type variable 'a' is interpreted as an unbound one. -- (1) pr :: [a] -> String -- (2) pr (_ :: [a]) = "[" ++ pr (undefined :: a) ++ "]" ======================================================================= Dear All, I got some problem when I try to compile the above program. The problem is due to the presence of a type variable 'a' in the body of the last instance declaration. How could I refer to the type variable of Arg [a] in the instance declaration? I tried these options 1) by giving an explicit declaration for pr 2) by giving a type signature to the argument of pr with -XPatternsSignatures The first option gives me back an error : Misplaced type signature: pr :: [a] -> String The type signature must be given where `pr' is declared The second option gives me an error: Test.hs:21:12: Not in scope: type variable `a' Would anybody help me to understand this problem? Thanks in advance. Kwanghoon

4 4

runghc error with glibc 2.8: unknown symbol `fstat64'
by prj＠po.cwru.edu 15 Dec '08

15 Dec '08

I get this error when running a script with runghc, if ghc was built againt glibc 2.8: ghc: /package/host/code.dogmap.org/foreign/ghc-6.10.1+spf+0/prefix/lib/ghc-6.10.1/base-4.0.0.0/HSbase-4.0.0.0.o: unknown symbol `fstat64' ghc: unable to load package `base' With glibc 2.6.1, it works. (At least, ghc 6.8.3 works with glibc 2.6.1. I didn't try ghc 6.10.1 with glibc 2.6.1, but ghc 6.8.3 gives the same error with glibc 2.8, so the ghc version doesn't seem to matter.) The output from "make" when building ghc didn't have any linking errors/warnings related to HSbase, as far as I can see. Has anyone seen anything like this? Any ideas? paul

1 0

ghc-paths
by Jens Petersen 12 Dec '08

12 Dec '08

Are there any plans to include ghc-paths in ghc itself? Jens

3 2

IMCROSS and ghc
by John Meacham 11 Dec '08

11 Dec '08

I was wondering if anyone has gotten ghc to work with IMCROSS[1]. I'm Cross is a way to build native windows and mac osx apps on linux. quite convinient for making distribution packages for those other platforms or if you want to use linux's toolset during your build. basically, IMCROSS installs a couple new gccs with names like /usr/local/bin/i386-mingw-gcc and so forth, is there some way to get ghc to use said non-native compiler as its back end? It seems that ghc will also need to build the libraries with different #define's as well to reflect the target windows or mac environment. [1] http://www.sandroid.org/imcross/ John -- John Meacham - ⑆repetae.net⑆john⑈

4 3

Parallel forkOS does not work on ubuntu
by Hoang Truong 10 Dec '08

10 Dec '08

Hello everybody, I am following "A Tutorial on Parallel and Concurrent Programming in Haskell" and I have a problem with making Haskell to use my multi-cores (Core 2 Quad CPU). The Haskel version I used is GHC 6.10.1, for Haskell 98. I compile my below program with command: ghc --make -threaded -debug thread0.hs, and run with: thread0 +RTS -N4 while watching the cpu usage on another terminal (by: mpstat -P ALL 1 100), but the program uses only one core of my Ubuntu Linux. Do any of you know why or has any suggestions? Below is my program: import Control.Concurrent import Control.Concurrent.MVar fib :: Int -> Int fib 0 = 0 fib 1 = 1 fib n = fib (n-1) + fib (n-2) dowork = putStrLn ("fib 35 = " ++ (show (fib 35))) threadA :: MVar Int -> MVar Int -> MVar Int -> IO () threadA valueToSendMVar valueToReadMVar valueToQuit = do -- some work dowork -- perform rendezvous putMVar valueToSendMVar 30 -- send value v <- takeMVar valueToReadMVar putStrLn ("result, fib 30 = " ++ (show v)) dowork -- notify done putMVar valueToQuit 0 -- send value threadB :: MVar Int -> MVar Int -> MVar Int -> IO () threadB valueToReceiveMVar valueToSendMVar valueToQuit = do -- some work dowork -- perform rendezvous by waiting z <- takeMVar valueToReceiveMVar putMVar valueToSendMVar (fib z) -- continue with other work dowork -- notify done putMVar valueToQuit 0 -- send value main :: IO () main = do aQuitA <- newEmptyMVar aQuitB <- newEmptyMVar aMVar <- newEmptyMVar bMVar <- newEmptyMVar forkOS (threadA aMVar bMVar aQuitA ) forkOS (threadB aMVar bMVar aQuitB ) -- wait for threadA and threadB takeMVar aQuitA takeMVar aQuitB return () Thanks a lot, Hoang

4 7

ghci linker and circular dependencies: bug or feature?
by Andrea Rossato 10 Dec '08

10 Dec '08

Hello, this is a followup of this: http://article.gmane.org/gmane.comp.lang.haskell.cafe/48644 which didn't have replays. In order to make the review a bit easier I prepared a minimal test case which, I believe, could prove there's a bug in the ghci linker. I'm not submitting a bug report because I'm not familiar with these problems and, in order not to waste other people's time, I'd rather have some preliminary review. All the code examples can be found here: http://gorgias.mine.nu/ffi-test/ Here a tarball of everything: http://gorgias.mine.nu/ffi-test.tar.gz Take a simple C library like this: #include <stdio.h> extern char my_var[]; void my_fun() { fprintf (stderr, "%s\n", my_var); } Since my_var is defined as external, the dynamic library compiled and linked with: gcc -Wall -fPIC -c -o mylib.o mylib.c gcc -shared -Wl,-soname,libmylib.so.1 -o libmylib.so.1.0 mylib.o would have my_var as undefined. If I write some Haskell bindings (Test.hsc) like this: module Test where import Foreign.C import Foreign #include <mylib.h> foreign import ccall unsafe "my_fun" my_cfun :: IO () my_fun :: IO () my_fun = my_cfun I'll need to include a stub.c file to initialize my_var: char my_var[] = "Hello World!!"; And now come my problems: 1. First I have a Cabal problem. If I set: extra-libraries: mylib this will be used also when compiling dist/build/Test_hsc_make, and, since libmylib.so.1.0 has an undefined reference to my_var, which will be initialized only later, by stub.c, the compilation of the bindings will fail with: Configuring mylib-0.1... Preprocessing library mylib-0.1... /tmp/ffi-test/libmylib.so: undefined reference to `my_var' collect2: ld returned 1 exit status linking dist/build/Test_hsc_make.o failed command was: /usr/bin/gcc -L/tmp/ffi-test -lmylib -L/usr/lib/ghc-6.10.1/base-4.0.0.0 [...] I can find a work-around by not setting cabal extra-libraries and instead setting ghc-options: -lmylib But when compiling a test file: import Test main = my_fun I'll need to pass -lmylib to ghc --make. 2. I also have ghci problem. If I try with: ghci test_lib.hs 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. Ok, modules loaded: Main. Prelude Main> main Loading package mylib-0.1 ... linking ... <interactive>: /home/andrea/.cabal/lib/mylib-0.1/ghc-6.10.1/HSmylib-0.1.o: unknown symbol `my_fun' ghc: unable to load package `mylib-0.1' Now, I have to remember to pass -lmylib: ghci -lmylib test_lib.hs GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading object (dynamic) mylib ... failed. <command line>: user specified .o/.so/.DLL could not be loaded (/tmp/ffi-test/libmylib.so: undefined symbol: my_var) Whilst trying to load: (dynamic) mylib Additional directories searched: (none) Now, the my_var symbol is included in: /home/andrea/.cabal/lib/mylib-0.1/ghc-6.10.1/HSmylib-0.1.o and indeed: nm --print-arma /home/andrea/.cabal/lib/mylib-0.1/ghc-6.10.1/HSmylib-0.1.o | grep my_var 0000001c D my_var So I desperately try: ghci /home/andrea/.cabal/lib/mylib-0.1/ghc-6.10.1/HSmylib-0.1.o -lmylib /tmp/ffi-test/bindings/test_lib.hs GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading object (static) /home/andrea/.cabal/lib/mylib-0.1/ghc-6.10.1/HSmylib-0.1.o ... done Loading object (dynamic) mylib ... failed. <command line>: user specified .o/.so/.DLL could not be loaded (/tmp/ffi-test/libmylib.so: undefined symbol: my_var) Whilst trying to load: (dynamic) mylib Additional directories searched: (none) Is this a bug? An intended behaviour? Is there a way out? What am I missing? Obviously the problem goes away if I link mylib.o with stub.o into libmylib.so.1.0. Thanks for your help. Andrea ps: here you can find a small shell script to automate the proposed test (included in the tarball linked above): http://gorgias.mine.nu/ffi-test/test_dynamic.sh

2 1

Three Recursively defined modules
by Chris Kuklewicz 08 Dec '08

08 Dec '08

Hi, As "hs-boot" is ghc specific method I am asking on this glasgow-haskell-users mailing list first. My hprotoc program converts message definitions into Haskell modules, and mimicking the expected OOP-like namespaces has been successful so far. It is possible to define messages and keys that create recursive modules dependencies, and I have left fixing this to the user. For the examples I have run across this has been possible to do manually. But I can easily write a file which generates three recursively defined modules with keys that I have not been able to fix with hs-boot files. I have created toy versions of the 3 modules and their "key"s which contain the problem. Can anyone see how to use hs-boot files to compile the three modules below? Note: The 3 modules ought to be the same aside from cyclic [a,b,c] replacement: > module A(A(..),akeybc,akeycb) where > > import B(B) > import B(bkeyac) > import C(C) > import C(ckeyab) > > data A = A { name :: String } > > akeybc :: Either B (Maybe C) > akeybc = Right Nothing > > akeycb :: Either C (Maybe B) > akeycb = Right Nothing > > instance Show A where > show a = concat [name a,show bkeyac,show ckeyab] > module B(B(..),bkeyca,bkeyac) where > > import A(A) > import A(akeybc) > import C(C) > import C(ckeyba) > > data B = B { name :: String } > > bkeyca :: Either C (Maybe A) > bkeyca = Right Nothing > > bkeyac :: Either A (Maybe C) > bkeyac = Right Nothing > > instance Show B where > show b = concat [name b,show ckeyba,show akeybc] > module C(C(..),ckeyab,ckeyba) where > > import A(A) > import A(akeycb) > import B(B) > import B(bkeyca) > > data C = C { name :: String } > > ckeyab :: Either A (Maybe B) > ckeyab = Right Nothing > > ckeyba :: Either B (Maybe A) > ckeyba = Right Nothing > > instance Show C where > show c = concat [name c,show akeycb,show bkeyca] It would be disappointing if I had to move the "key"s into separate modules/namespaces to allow for a solution using hs-boot files. Thanks, Chris

2 1

Type checker loops with type families, overlapping and undecidable instances
by José Pedro Magalhães 08 Dec '08

08 Dec '08

Hello all, Please consider the following code: {-# OPTIONS -Wall #-} > {-# LANGUAGE FlexibleContexts #-} > {-# LANGUAGE FlexibleInstances #-} > {-# LANGUAGE TypeOperators #-} > {-# LANGUAGE TypeFamilies #-} > {-# LANGUAGE OverlappingInstances #-} > {-# LANGUAGE UndecidableInstances #-} > > module Test where > > -- Some view > class Viewable a where > type View a > to :: a -> View a > > -- Structural representations > data Unit = Unit > data a :+: b = L a | R b > > instance Viewable Unit where > type View Unit = Unit > to = id > > instance (Viewable a, Viewable b) => Viewable (a :+: b) where > type View (a :+: b) = a :+: b > to = id > > -- Worker class > class F' a where > f' :: a -> () > > instance F' Unit where > f' Unit = () > > instance (F a, F b) => F' (a :+: b) where > f' (L x) = f x > f' (R x) = f x > > > -- Dispatcher class > class (Viewable a, F' (View a)) => F a where > f :: a -> () > f = f' . to > > instance F Unit where > f = f' > > instance (F a, F b) => F (a :+: b) where > f = f' > > -- All generic instances > instance (Viewable a, F' (View a)) => F a > > > -- A recursive datatype > data Nat = Zero | Succ Nat > > -- Instance of Viewable > instance Viewable Nat where > type View Nat = Unit :+: Nat > to = undefined > > -- Uncommenting the line below causes the typechecker to loop (GHC 6.10.1, > Windows) > --test = f Zero > Is this expected behavior or a bug? Thanks, Pedro

5 5

Re: Weak pointers and STM
by Simon Marlow 08 Dec '08

08 Dec '08

The way to use finalizers is in conjunction with an exception handler that provides an absolute guarantee that the resource will be reclaimed on exit. Note that Java doesn't guarantee to run finalizers on exit either: http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Runtime.html#runFinalizer… Although in Java it's for different reasons. We can give more guarantees to C finalizers because they're much simpler: - a C finalizer can't synchronise with other Haskell code, including Haskell finalizers. - we don't have to worry about whether a C finalizer refers to other finalizable objects - we don't mind if a C finalizer blocks: that's the programmer's problem. Cheers, Simon Lennart Augustsson wrote: > From a theoretical perspective I'd say that they are completely > useless, because there's no guarantee that the finalizer will ever > run. You might as well throw them away as use them and there would be > the same guarantees. > From a practical perspective they are useful, because they probably > run. So you can use them to reclaim most resources. > > I realize that the situation is complicated in ghc, but it also means > that to get finalizers with guarantees you have to implement them > yourself rather than relying on the ghc runtime system, which can be > quite tedious. > > -- Lennart > > On Mon, Dec 8, 2008 at 9:59 AM, Simon Marlow <marlowsd(a)gmail.com> wrote: >> Lennart Augustsson wrote: >>> Finalizers without guarantees, like what ghc implements, are totally >>> useless. Since there is no guarantee that the finalizer will ever run >>> attaching one is a no-op. It has bitten me several times. I wish ghc >>> implemented finalizers according to the ffi spec. >> We do plan to do that (I'm sure you're aware of bug #1364), however I'm sure >> you're also aware that GHC's finalizers are more general than the FFI spec >> requires in that finalizers can be Haskell computations, and it is this that >> leads to the lack of guarantees. Implementing the FFI-style finalizers >> requires us to treat C finalizers as a special case, rather than >> implementing them as foreign calls from Haskell finalizers, which is a bit >> of a pain. >> >> I disagree that finalizers are completely useless. They're just not useful >> for some of the things you might like them to be useful for, like guaranteed >> resource reclamation. >> >>> -- Lennart (iPhone) >> Cheers, >> Simon (MS natural keyboard and 28" LCD screen) >> >>> On Dec 7, 2008, at 13:12, "Claus Reinke" <claus.reinke(a)talk21.com> wrote: >>> >>>>> Adding finalizers to arbitrary objects was useful for the memo table >>>>> application we had in mind when weak pointers were introduced, but for all >>>>> the other applications I've come across since then, we really want to add >>>>> finalizers to objects whose lifetimes are under programmer control. Notice >>>>> how ForeignPtrs attach the finalizer carefully to the MutVar# inside the >>>>> ForeignPtr, not the ForeignPtr itself. >>>> One application that was effectively killed by GHC's approach to >>>> finalizers was GHood (I lost interest when it became apparent that >>>> GHC was moving away from giving any kinds of guarantees about >>>> finalizers). The idea was that, just as unsafePerformIO gives us a >>>> way to instrument the evaluator, so finalizers could have given us a way >>>> to instrument garbage collection. Then GHood could not only >>>> have shown when which parts of which structure are first observed >>>> (how and when structures get unfolded) but also (roughly) when which >>>> parts of which structure become unreachable (how and when >>>> structures disappear again). That would have made a very nice tool. >>>> >>>> But it would have needed finalizers on arbitrary objects that are >>>> actually guaranteed to be run, preferably promptly, but not early. Given >>>> the application, I would have considered wrapping/annotating those objects >>>> in some transparent way, not visible to the original program, but forcing >>>> the memory manager to keep track of that object even if that means worse >>>> code. Only that there are no guarantees whatsoever on these finalizers >>>> anymore (there were some back then, but it emerged that they weren't backed >>>> up by the implementation). >>>> Which also hurts other, table-like, applications: I have an application >>>> where I need to keep track of synchronous communication channels, basically: >>>> advance each live channel at every step. Now, I would like to attach >>>> finalizers to the channels, so that when there are no more threads having >>>> references to a channel, the channel gets removed >>>> from the tracking table. But without finalizer guarantees, there is no >>>> guarantee that the table will not simply keep accumulating more and >>>> more of those dynamically created channels.. >>>> >>>> I, for one, would like to have good support for "adding finalizers to >>>> arbitrary objects with useful run guarantees". Actually, it is a bit hard >>>> to understand what finalizers without any guarantees (System.Mem.Weak) >>>> are supposed to achieve? >>>> >>>> Claus >>>> >>>> _______________________________________________ >>>> Glasgow-haskell-users mailing list >>>> Glasgow-haskell-users(a)haskell.org >>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >>

2 1