January 2004 - Glasgow-haskell-users

Generics and type classes
by Stefan Reich 30 Jan '04

30 Jan '04

Hi, please consider the following module: module TypeTest where import Data.Generics class Data a => MyClass a where special :: a -> a generic :: MyClass a => a -> a generic = everywhere (mkT special) The general idea is to define traversals about data types not known in advance. The data types must implement a "special" transformation which is then automatically extended to a "generic" transformation. The definition of "generic" is but an example. In reality, there might also be special2 and special3 beside "special", and "generic" might combine the three special transformations in some way. The problem is this - the module doesn't compile. TypeTest.hs:1: Ambiguous type variable `b' in the top-level constraint: `MyClass b' arising from use of `special' at TypeTest.hs:9 I suppose the type of "mkT special" is ambiguous. But how can I change that? No type annotation or combination of type annotations seems to help. Suggestions appreciated, -Stefan

1 0

linking problems after switching from GHC5 to GHC6
by Volker Wysk 30 Jan '04

30 Jan '04

Hello I can't link with a library any longer, after switching from ghc5 to ghc6.2. I've recompiled the library with the new compiler version, so that's not the problem. With GHC5: everything is fine: ~/src/hsunix $ ghc --version The Glorious Glasgow Haskell Compilation System, version 5.04.2 ~/src/hsunix $ make clean ... ~/src/hsunix $ make build/test0 ghc `src/lib/hsunix-config --local --cflags` -hidir build -odir build -ibuild -c -o build/HsUnixArgs.o src/lib/HsUnixArgs.hs ghc `src/lib/hsunix-config --local --cflags` -hidir build -odir build -ibuild -c -o build/HsUnixShell.o src/lib/HsUnixShell.hs ... ar cqs build/libhsunix.a build/HsUnixArgs.o build/HsUnix.o build/HsUnixMisc.o build/HsUnixPaths.o build/HsUnixShell.o build/HsUnixCommands.o build/HsUnixProcErr.o build/hsunix.o ghc `src/lib/hsunix-config --local --cflags` -hidir build -odir build -ibuild -ohi build/test0.hi -c -o build/test0.o src/test/test0.hs ghc -o build/test0 build/test0.o -odir build `src/lib/hsunix-config --local --libs` ~/src/hsunix $ src/lib/hsunix-config --local --libs build/libhsunix.a -syslib lang -syslib posix -syslib text -syslib util With GHC6, I get errors about undefined symbols. It are symbols which are defined in the library (libhsunix.a): ~/src/hsunix $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.2 ~/src/hsunix $ make clean ... ~/src/hsunix $ make build/test0 ghc `src/lib/hsunix-config --local --cflags` -hidir build -odir build -ibuild -c -o build/HsUnixArgs.o src/lib/HsUnixArgs.hs ghc `src/lib/hsunix-config --local --cflags` -hidir build -odir build -ibuild -c -o build/HsUnixShell.o src/lib/HsUnixShell.hs ... ar cqs build/libhsunix.a build/HsUnixArgs.o build/HsUnix.o build/HsUnixMisc.o build/HsUnixPaths.o build/HsUnixShell.o build/HsUnixCommands.o build/HsUnixProcErr.o build/hsunix.o ghc `src/lib/hsunix-config --local --cflags` -hidir build -odir build -ibuild -ohi build/test0.hi -c -o build/test0.o src/test/test0.hs ghc -o build/test0 build/test0.o -odir build `src/lib/hsunix-config --local --libs` build/test0.o(.text+0x25): In function `__stginit_Main_': : undefined reference to `__stginit_HsUnix_' build/test0.o(.text+0xec): In function `Main_main_srt': : undefined reference to `HsUnix_mainwrapper_closure' build/test0.o(.text+0x151): In function `Main_main_entry': : undefined reference to `HsUnix_mainwrapper_closure' collect2: ld returned 1 exit status make: *** [build/test0] Error 1 rm build/test0.o Oddly, the problem does not occur when I directly pass the haskell source file to the compiler instead of the object file which is created from it: ~/src/hsunix $ ghc -o build/test0 src/test/test0.hs -odir build `src/lib/hsunix-config --local --libs` `src/lib/hsunix-config --local --cflags` ^^^^^^^^^^^^^^^^^ instead of build/test0.o which is created from it (succeeds) Does anyone have any idea of what's wrong? I find this especially strange, because it works with GHC5. Bye, V.W. -- Volker Wysk <post(a)volker-wysk.de> http://www.volker-wysk.de

3 3

RE: Problem with ghc on Windows ME
by Simon Marlow 30 Jan '04

30 Jan '04

[ file actually attached this time... ] > > In released software, I'm using only system so far, so won't be > > affected negatively. But I still haven't managed to work around the > > "works in win98"/"fails in winXP" problem I mentioned, and have so > > far avoided trying rawSystem because of the version problem. If you > > can offer a workaroung to the version problem, I'll try whether > > rawSystem is any help in my case. > > I've attached a standalone rawSystem implementation that works on both > 6.0.1 and 6.2 on Windows (on Unix it only works with 6.2; if you want > 6.0.1 support for Unix too you'll need an extra .c file). > > I'd be interested to know if this helps with your win98/winXP problem; > at the least it should free you from having to think about > one layer of > quoting. > > > Generally, it'd be great if working code would less often break with > > new releases (oh, and a portable popen2, while we're at it!-). > > We try our best! Remember that patchlevel releases only fix > bugs, never > change interfaces, so working code should never break when moving to a > new patchlevel release. Major releases can change > interfaces. We also > do a great deal of testing on every release, but bugs inevitably creep > in, especially on platforms other than our main development platform > (Linux). Which is why we're grateful for any help we can get from the > community... > > Cheers, > Simon > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >

1 0

RE: Problem with ghc on Windows ME
by Simon Marlow 30 Jan '04

30 Jan '04

> In released software, I'm using only system so far, so won't be > affected negatively. But I still haven't managed to work around the > "works in win98"/"fails in winXP" problem I mentioned, and have so > far avoided trying rawSystem because of the version problem. If you > can offer a workaroung to the version problem, I'll try whether > rawSystem is any help in my case. I've attached a standalone rawSystem implementation that works on both 6.0.1 and 6.2 on Windows (on Unix it only works with 6.2; if you want 6.0.1 support for Unix too you'll need an extra .c file). I'd be interested to know if this helps with your win98/winXP problem; at the least it should free you from having to think about one layer of quoting. > Generally, it'd be great if working code would less often break with > new releases (oh, and a portable popen2, while we're at it!-). We try our best! Remember that patchlevel releases only fix bugs, never change interfaces, so working code should never break when moving to a new patchlevel release. Major releases can change interfaces. We also do a great deal of testing on every release, but bugs inevitably creep in, especially on platforms other than our main development platform (Linux). Which is why we're grateful for any help we can get from the community... Cheers, Simon

1 0

RE: Problem with ghc on Windows ME
by Simon Peyton-Jones 30 Jan '04

30 Jan '04

> *** Literate pre-processor C:\GHC\GHC-6.2\unlit.exe -h Demo.lhs Demo.lhs > C:\WINDOWS\TEMP\ghc-1160737.lpp > > Failed: C:\GHC\GHC-6.2\unlit.exe -h Demo.lhs Demo.lhs > C:\WINDOWS\TEMP\ghc-1160737.lpprawSystem: does not exist (No such file or > directory) *** Deleting temp files Deleting: C:/WINDOWS/TEMP/ghc-1160737.lpp > Warning: deleting non-existent C:/WINDOWS/TEMP/ghc-1160737.lpp Simon and I spent an hour getting to the bottom of Gour's problem. Short answer: It's a bug in GHC6.2 that you really can't get round. It only shows up on Win ME/98/95, and it really makes GHC6.2 unusable on those platforms. We'll fix it in 6.2.1, but apart from that you'll have to back up to 6.0.1. Medium answer: an oversight meant that GHC6.2 invokes Win32 external commands (like gcc, unlit etc) with double-backslashes in the arguments: cat foo\\baz On NT and XP, these double-backslashes are harmless, but not on WinME/98/95, which is why we didn't notice it. The long answer is below for those who are interested, reproduced from new comments in libraries/base/System/Cmd.hs Simon M sent round a source patch yesterday. It'd be great if someone could confirm that it really works. Simon LONG ANSWER GHC uses 'rawSystem' to invoke gcc, unlit etc: rawSystem :: FilePath -> [String] -> IO ExitCode {- | The computation @rawSystem cmd args@ runs the operating system command whose file name is @cmd@, passing it the arguments @args@. It bypasses the shell, so that @cmd@ should see precisely the argument strings @args@, with no funny escaping or shell meta-syntax expansion. (Unix users will recognise this behaviour as @execvp@, and indeed that's how it's implemented.) It will therefore behave more portably between operating systems than @system@. -} {- ------------------------------------------------------------------------ - IMPORTANT IMPLEMENTATION NOTES (see also libraries/base/cbits/rawSystem.c) On Unix, rawSystem is easy to implement: use execvp. On Windows it's more tricky. We use CreateProcess, passing a single command-line string (lpCommandLine) as its argument. (CreateProcess is well documented on http://msdn.microsoft/com.) - It parses the beginning of the string to find the command. If the file name has embedded spaces, it must be quoted, using double quotes thus "foo\this that\cmd" arg1 arg2 - The invoked command can in turn access the entire lpCommandLine string, and the C runtime does indeed do so, parsing it to generate the traditional argument vector argv[0], argv[1], etc. Again, to break it into argument items, any spaces must be quoted using double quote thus cmd "this is arg 1" "this is arg 2" What if an argument itself contains double-quotes? (File names can't can't, on Windows.) Then the quote must be escaped with a backslash. If we call Create Process with this lpArgument: cmd "Foo=\"baz\"" arg2 then cmd will see argv[1] as Foo="baz" However, experiments show that backslashes themselves must *not* be escaped. That is, to get a backslash in an argument, just put backslash, even inside quotes. For eaxmple, this works fine to show the contents of the file foo\baz cat "foo\baz" If you escape the backslash, thus cat "foo\\baz" then @cat@ will see argument foo\\baz, and on WinME/98/95 you'll get "can't find file foo\\baz". (As it happens, WinNT/XP commands don't mind double backslashes, but it's still a bug, given rawSystem's claim to pass exactly args to the command.) [NOTE: this was the bug in 6.2.] BOTTOM LINE: 1 We wrap the command, and each argument, in quotes 2 Inside the quotes, we escape any double-quote characters (but nothing else) 3 Then concatenate all these quoted things together, separated with spaces Steps 1,2 are done by the function 'translate' below. Question: how do you get the string \" into an argument? Turns out that the argument "\\"" does not do the job. (This turns into a single \.) Puzzling but probably not important in practice. Note: CreateProcess does have a separate argument (lpApplicationName) with which you can specify the command, but we have to slap the command into lpCommandLine anyway, so that argv[0] is what a C program expects (namely the application name). So it seems simpler to just use lpCommandLine alone, which CreateProcess supports. ------------------------------------------------------------------------ ----- -}

3 2

RE: Problem with ghc on Windows ME
by Simon Marlow 29 Jan '04

29 Jan '04

> > It's called 'raw' because it is supposed to get the > arguments through > > *unmodified* to the called program. No file globbing, no > escape stuff, nothing. > > That's exactly what I'm worried about: it seems that rawSystem is > *not* passing the arguments unmodified, but tries to compensate for > windows interpretation, from a unix perspective (*). No, the effect is that the arguments are passed unmodified to the program. The implementation of rawSystem might have to do some compensation under the hood (eg. on Windows), but that's not visible to the client. > As long as "raw" means "unmodified", I just have the problem of > finding the appropriate documentation for the system I'm working > on (after all, that's why it's in System). But if there are two > interpreters fighting with each other for some unstable balance, > things do not look so promising. > > For instance, I can't use rawSystem in ghc-6.x because there are > already two different versions in circulation, and a third one > planned. So, instead of simplifying my code, I'd have to triplicate > it, and add version testing, which adds preprocessing.. This is an unfortunate situation, granted. ghc-6.0.x had a version of rawSystem that was not very raw: on Windows there was a layer of translation between rawSystem and the invoked program, and on Unix it didn't even allow you to pass any arguments to the program. We thought this was wrong, and decided to make rawSystem truly raw. Unfortunately we got it slightly wrong in 6.2. 6.2.1 will be better (I hope), and in the meantime we can offer an implementation of rawSystem that you can use locally to work around the differences - how does that sound? > Therefore, my suggestion would be to keep the rawSystem from > ghc-6.0.1 (which doesn't seem to do any interpretation?), and > to provide a system-specific escape function > > System.Cmd.escape :: String -> String -> String > -- (System.Cmd.escape chars string) escapes occurrences of > -- chars in string, according to convention on the current > -- system > > If really necessary, there could be a convenience function > somewhat like: > > -- try to do "the right thing" > System.Cmd.rawSystem' :: String -> [String] -> IO ExitCode > System.Cmd.rawSystem' path args = > rawSystem $ concat (path:[' ':(escape "\\\"" a) | a <- args]) I don't think it's necessary to do any of this, if rawSystem works as it's intended. But I may have misunderstood your intention... Cheers, Simon

2 1

RE: Problem with ghc on Windows ME
by Simon Marlow 29 Jan '04

29 Jan '04

After Googling around a bit, I found this description of exactly how Windows interprets command lines in the C runtime: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccelng /htm/progs_12.asp As you can see, the rules are indeed very strange, but they are invertible. I think this code should do the trick: translate :: String -> String translate str = '"' : snd (foldr escape (True,"\"") str) where escape '"' (_, str) = (True, '\\' : '"' : str) escape '\\' (True, str) = (True, '\\' : '\\' : str) escape '\\' (False, str) = (False, '\\' : str) escape c (_, str) = (False, c : str) Cheers, Simon > -----Original Message----- > From: glasgow-haskell-users-bounces(a)haskell.org > [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf > Of Simon Marlow > Sent: 29 January 2004 11:31 > To: Claus Reinke; Simon Peyton-Jones; > glasgow-haskell-users(a)haskell.org > Subject: RE: Problem with ghc on Windows ME > > > > So does that mean functionality has been lost in the move from > > ghc-6.0.1? > > No, the behaviour is improved in 6.2 because we're now > careful to escape > quotes before passing the command-line to the operating system. > > I think confusion has arisen because Simon pointed out that there's no > way, on Windows, to pass this sequence of characters as an > argument to a > command: > > \" > > This is not entirely true, I just discovered that the > sequence \\\" will > turn into \". But in general, the sequence \\ does not turn into \. > Windows' command-line quoting rules are highly mysterious, to say the > least. > > So the patch I posted is not complete. It looks like rawSystem should > additionally translate \" as \\\". > > > Because that (on win98) happily accepts such useful > > contraptions as > > > > System.Cmd.rawSystem "\"c:\\silly > > space\\Vim\\vim62\\gvim.exe\" --servername GVIM --remote-send > > \":echo \\\"hi \\\\\\\" there\\\"<cr>\"" >>= print > > The idea is that you should pass to rawSystem *exactly* the > command and > arguments you want to run, with no quoting except that required by the > Haskell lexical syntax. You'll notice that rawSystem now takes the > command and list of arguments separately in 6.2. The > implementation of > rawSystem will attempt to compensate for the internal translation that > Windows does on the command-line; on Unix no translation is necessary. > So clients of rawSystem should be more portable, because they > don't have > to know about quoting that happens under the hood. > > Your example will probably work once it's reformulated for > 6.2's version > of rawSystem, and once we fix rawSystem in light of the \\\" hack I > discovered above. > > Cheers, > Simon > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >

3 2

Re: Problem with ghc on Windows ME
by C.Reinke 29 Jan '04

29 Jan '04

> It's called 'raw' because it is supposed to get the arguments through > *unmodified* to the called program. No file globbing, no escape stuff, > nothing. That's exactly what I'm worried about: it seems that rawSystem is *not* passing the arguments unmodified, but tries to compensate for windows interpretation, from a unix perspective (*). As long as "raw" means "unmodified", I just have the problem of finding the appropriate documentation for the system I'm working on (after all, that's why it's in System). But if there are two interpreters fighting with each other for some unstable balance, things do not look so promising. For instance, I can't use rawSystem in ghc-6.x because there are already two different versions in circulation, and a third one planned. So, instead of simplifying my code, I'd have to triplicate it, and add version testing, which adds preprocessing.. Therefore, my suggestion would be to keep the rawSystem from ghc-6.0.1 (which doesn't seem to do any interpretation?), and to provide a system-specific escape function System.Cmd.escape :: String -> String -> String -- (System.Cmd.escape chars string) escapes occurrences of -- chars in string, according to convention on the current -- system If really necessary, there could be a convenience function somewhat like: -- try to do "the right thing" System.Cmd.rawSystem' :: String -> [String] -> IO ExitCode System.Cmd.rawSystem' path args = rawSystem $ concat (path:[' ':(escape "\\\"" a) | a <- args]) Since the implementation of rawSystem in the current binary release appears to be buggy, there is still a chance to declare the original behaviour as the intended one and have the same code work in all versions of ghc-6 that may be installed out there.. Claus (*) I can't think of any case where I could pretend that a rawSystem call on unix could be the same as one on any other system - not with all the system variations around on windows alone (mingw ghc/cygwin ghc/international variants of windows/different versions of windows/..). So what I really need is a way to specify different code, depending on what system I'm on (which seems to be the purpose of System.Info). And for that it doesn't really help me if I have to think about what a unix system call would do while writing my windows system call - it is well-meant, but it just adds complications.

2 1

RE: Problem with ghc on Windows ME
by Simon Marlow 29 Jan '04

29 Jan '04

> So does that mean functionality has been lost in the move from > ghc-6.0.1? No, the behaviour is improved in 6.2 because we're now careful to escape quotes before passing the command-line to the operating system. I think confusion has arisen because Simon pointed out that there's no way, on Windows, to pass this sequence of characters as an argument to a command: \" This is not entirely true, I just discovered that the sequence \\\" will turn into \". But in general, the sequence \\ does not turn into \. Windows' command-line quoting rules are highly mysterious, to say the least. So the patch I posted is not complete. It looks like rawSystem should additionally translate \" as \\\". > Because that (on win98) happily accepts such useful > contraptions as > > System.Cmd.rawSystem "\"c:\\silly > space\\Vim\\vim62\\gvim.exe\" --servername GVIM --remote-send > \":echo \\\"hi \\\\\\\" there\\\"<cr>\"" >>= print The idea is that you should pass to rawSystem *exactly* the command and arguments you want to run, with no quoting except that required by the Haskell lexical syntax. You'll notice that rawSystem now takes the command and list of arguments separately in 6.2. The implementation of rawSystem will attempt to compensate for the internal translation that Windows does on the command-line; on Unix no translation is necessary. So clients of rawSystem should be more portable, because they don't have to know about quoting that happens under the hood. Your example will probably work once it's reformulated for 6.2's version of rawSystem, and once we fix rawSystem in light of the \\\" hack I discovered above. Cheers, Simon

3 2

RE: Network problem with ghc on WinXP
by Simon Marlow 29 Jan '04

29 Jan '04

Is there a reason not to export PortNumber abstractly? I can't think of one off-hand. Cheers, Simon > -----Original Message----- > From: glasgow-haskell-users-bounces(a)haskell.org > [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf > Of Sigbjorn Finne > Sent: 29 January 2004 06:37 > To: robin abraham > Cc: glasgow-haskell-users(a)haskell.org > Subject: Re: Network problem with ghc on WinXP > > Hi there, > > looks like a network byte-order vs host byte-order gotcha. > Never use the PortNum constructor, but declare 'portnum' > to have type PortNumber and simply drop the use of PortNum > in your code alltogether. Alternatively, use intToPortNumber > to translate between Int and PortNumber. > > hth > --sigbjorn > > ----- Original Message ----- > From: "robin abraham" <abraharo(a)cs.orst.edu> > To: <glasgow-haskell-users(a)haskell.org> > Sent: Wednesday, January 28, 2004 21:57 > Subject: Network problem with ghc on WinXP > > > > Hi, > > > > I have ghc-6.0.1 on WinXP and Solaris. I have a simple echo server > (server.hs > > given below) and client (client.hs given below) and I encounter the > following: > > 1) server.hs compiled and running on Solaris: > > a) client.hs (Solaris) can connect. > > b) client.hs (WinXP) cannot connect. > > c) telnet (WinXP) can connect. > > d) telnet (Solaris) can connect. > > e) Scan of port 3000 shows server is listening. > > > > 2) server.hs compiled and running on WinXP: > > a) client.hs (Solaris) cannot connect. > > b) client.hs (WinXP) can connect. > > c) telnet (WinXP) cannot connect. > > d) telnet (Solaris) cannot connect. > > e) Scan of ports does not show server. > > > > Basically, when the server is running on WinXP, only the > Haskell program > > client.hs (also running on the same WinXP machine) can > "converse" with it > > through the socket connection. To verify this, I wrote a > client in C# - > from the > > WinXP machine, it can connect to server running on my > Solaris machine but > not to > > server on the same WinXP machine. > > > > Why isn't the server program on WinXP not behaving itself? Any > help/guidance > > would be highly appreciated. > > > > Thank you. > > Robin. > > > > -- server.hs > > module Main where > > > > import SocketPrim > > import Concurrent > > import System (getArgs,exitFailure) > > import Exception(finally) > > import MVar > > import IO > > > > server_sock :: IO (Socket) > > server_sock = do > > s <- socket AF_INET Stream 6 > > setSocketOption s ReuseAddr 1 > > bindSocket s (SockAddrInet (PortNum portnum) iNADDR_ANY) > > listen s 2 > > return s > > > > echo_server :: Socket -> IO () > > echo_server s = do > > (s', clientAddr) <- accept s > > h <- socketToHandle s' ReadWriteMode > > proc <- read_data s' 0 > > putStrLn ("server processed "++(show proc)++" bytes") > > sClose s' > > where > > read_data sock totalbytes = do > > str <- recv sock 18 > > putStrLn ("Server recv: " ++ str) > > if ((length str) >= 18) > > then do > > putStrLn ("Server read: " ++ str) > > writ <- send sock str > > putStrLn ("Server wrote: " ++ str) > > read_data sock $! (totalbytes+(length $! str)) > > else do > > putStrLn ("server read: " ++ str) > > return totalbytes > > > > message = "Hello there sailor" > > portnum = 3000 > > > > main = withSocketsDo $ do { > > ~[n] <- getArgs; > > ssock <- server_sock; > > s <- myForkIO (echo_server ssock); > > join s; > > putStrLn "join s"; > > } > > > > myForkIO :: IO () -> IO (MVar ()) > > myForkIO io = do > > mvar <- newEmptyMVar > > forkIO (io `finally` putMVar mvar ()) > > return mvar > > > > join :: MVar () -> IO () > > join mvar = readMVar mvar > > > > -- end of server.hs > > > > -- *********************************************** > > > > -- client.hs > > > > module Main where > > > > import SocketPrim > > import Concurrent > > import System (getArgs,exitFailure) > > import Exception(finally) > > import MVar > > import IO > > > > local = "128.193.39.108" > > message = "Hello there sailor" > > portnum = 3000 > > > > client_sock = do > > s <- socket AF_INET Stream 6 > > ia <- inet_addr local > > connect s (SockAddrInet (PortNum portnum) ia) > > return s > > > > echo_client n = do > > s <- client_sock > > drop <- server_echo s n > > sClose s > > where > > server_echo sock n = if n > 0 > > then do > > send sock message > > putStrLn ("Client wrote: " ++ message) > > str <- recv sock 19 > > if (str /= message) > > then do > > putStrLn ("Client read error: " ++ str) > > exitFailure > > else do > > putStrLn ("Client read success") > > server_echo sock (n-1) > > else do > > putStrLn "Client read nil" > > return [] > > > > main = withSocketsDo $ do > > ~[n] <- getArgs > > c <- myForkIO (echo_client (read n::Int)) > > join c > > putStrLn "join c" > > > > myForkIO :: IO () -> IO (MVar ()) > > myForkIO io = do > > mvar <- newEmptyMVar > > forkIO (io `finally` putMVar mvar ()) > > return mvar > > > > join :: MVar () -> IO () > > join mvar = readMVar mvar > > > > -- end of client.hs > > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >

2 1