October 2009 - Glasgow-haskell-users

partially applied type synonyms
by Arie Peterson 05 Mar '12

05 Mar '12

Dear list, Is there a good reason that partially applied type synonyms cannot be made instances of classes? - A simple example would be making the identity type 'Id' ("type Id x = x") instance of 'Monad'. This would eliminate the need for some silly occurrences of 'runIdentity', and perhaps narrow the gap between monads and monad transformers. - The reason I complain about this now is a more involved example, where introducing a newtype to work around the restriction is not an option. Well, not as far as I can see now, anyway. Partially applied type synonyms are, in a sense, the anonymous functions at the type level, and one might argue that they deserve the same 'first-class member status' as the lambda at the value level. Kind regards, Arie Peterson

3 2

Update on GHC 6.12.1
by Simon Peyton-Jones 09 Feb '10

09 Feb '10

Folks This is an update on the status of GHC 6.12. FIRST, as you probably know, Hackage and the Haskell Platform is allowing GHC HQ to get out of the libraries business. So the plan is - We release GHC 6.12 with very few libraries - Bill Library Author downloads GHC 6.12 and tests his libraries - The next Haskell Platform release packages GHC 6.12 with these tested libraries - Joe User downloads the Haskell Platform. - Four months later there's a new HP release, still with GHC 6.12, but with more or better libraries. The HP release cycle is decoupled from GHC So if you are Joe User, you want to wait for the HP release. Don't grab the GHC 6.12 release. It'll be perfectly usable, but only if you use (an up to date) cabal-install to download libraries, and accept that they may not be tested with GHC 6.12. SECOND, we have produced Release Candidate 1 for GHC 6.12.1, and are about to produce RC2. However, before releasing 6.12 we'd like to compile all of Hackage, in case doing so reveals bugs in GHC's APIs (which are not supposed to change). But we can't do that until an update to cabal-install is ready. (We don't expect this dependency to happen all the time, but it does hold for 6.12.) Duncan has been working on the cabal-install update, and expects to release by end November. So the timetable looks like this: - Very soon: GHC 6.12.1 release candidate 2 - End Nov: cabal-install release - ...test GHC against Hackage... - Early Dec: release GHC 6.12 - ...library authors and HP folk get busy... - End Jan (?): Haskell Platform release - ...Joe User downloads HP... FINALLY, below I summarise a late change that's been pending for a long time, which I propose to sneak into RC2, for reasons explained below. If you can see a good reason not to do this, yell. Simon Recursive do-notation. ~~~~~~~~~~~~~~~~~~~~~~ The change is this. Instead of writing mdo { a <- getChar ; b <- f c ; c <- g b ; putChar c ; return b } you would write do { a <- getChar ; rec { b <- f c ; c <- g b } ; putChar c ; return b } That is, * 'mdo' is eliminated * 'rec' is added, which groups a bunch of statements into a single recursive statement See http://hackage.haskell.org/trac/ghc/ticket/2798 This 'rec' thing is already present for the arrow notation, so it makes the two more uniform. Moreover, 'rec' lets you say more precisely where the recursion is (if you want to), whereas 'mdo' just says "there's recursion here somewhere". Lastly, all this works with rebindable syntax (which mdo does not). Currently 'mdo' is enabled by -XRecursiveDo. So we propose to deprecate this flag, with another flag -XDoRec to enable the 'rec' keyword. The main question is not whether to make this change, but when. I'm inclined to do put it into GHC 6.12, even though it's late in the day because then we can take mdo out of 6.14 altogether. Another minor question is whether "-XDoRec" is a good name for the flag. We can't really use "-XRecursiveDo" because that's the one we are deprecating!

12 18

Three patches for cabal
by Niklas Broberg 09 Nov '09

09 Nov '09

(Trying again since my previous patches were too big for the list.) While doing a survey[1] of the extensions registered with Cabal, I came across two warts in the list of constructors, and one constructor that should be deprecated. First there's the constructor called TransformListComp, which should really be named GeneralizedListComp, since the constructor should describe the extension and not the implementation scheme. Second there's the constructor NoMonoPatBinds, which actually describes the default Haskell 98 behavior, even if GHC has a different default. It's GHC's behavior that is the extension, so the constructor in cabal should really be named MonoPatBinds. Also, the PatternSignatures constructor has been deprecated in GHC and superceded by ScopedTypeVariables. The attached patches (three in one file) adds the proposed new constructors, deprecates the old ones, and adds documentation. Cheers, /Niklas

8 15

ANNOUNCE: GHC 6.12.1 Release Candidate 1
by Ian Lynagh 07 Nov '09

07 Nov '09

Hi all, We are pleased to (finally!) announce the first release candidate for GHC 6.12.1: http://darcs.haskell.org/~ghc/dist/6.12.1rc1/ As well as the source tarball: ghc-6.12.0.20091010-src.tar.bz2 there are installers for Windows (i386) and OS X (i386), and binary distributions for x86_64/Linux and i386/Linux. For the Linux binary distributions, the "linux-n" tarballs are recommended over the "linux" tarballs. 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

17 36

6.12.1 Release Candidate: profiling and libHSffi_p.a
by Neil Brown 07 Nov '09

07 Nov '09

Hi, I tried profiling a program with the GHC 6.12 release candidate. I got this: $ ghc -O1 -prof -auto-all --make CommsTime.hs [1 of 1] Compiling Main ( CommsTime.hs, CommsTime.o ) Linking CommsTime ... /usr/bin/ld: cannot find -lHSffi_p collect2: ld returned 1 exit status Googling turned up this link, which suggests this problem was fixed earlier this year: http://www.mail-archive.com/cvs-ghc@haskell.org/msg13546.html However: $ find ~ -iname "libHSffi*" /home/nccb2/lib/ghc-6.12.0.20091010/libHSffi.a /home/nccb2/lib/ghc-6.12.0.20091010/libHSffi-ghc6.12.0.20091010.so /home/nccb2/ghc-6.11.20090915/libffi/libHSffi.a /home/nccb2/ghc-6.11.20090915/libffi/libHSffi-ghc6.11.20090915.so /home/nccb2/ghc-6.12.0.20091010/libffi/libHSffi-ghc6.12.0.20091010.so /home/nccb2/ghc-6.12.0.20091010/libffi/libHSffi.a /home/nccb2/ghc-6.12.0.20091010/libffi/libHSffi_p.a This seems to indicate that the library is built (/home/nccb2/ghc-6.12.0.20091010 is where I built GHC) but not installed on my system. This is a Debian 32-bit system, and I don't remember passing any options to the GHC configure command besides --prefix. Neil.

2 1

How to know data size in UDP?
by Kazu Yamamoto 04 Nov '09

04 Nov '09

Hello, I'm trying to implement DNS resolver without any external C libraries for my daemon program which uses DNS lookup. I know the "hsdns" library exists. But since it calls GNU asynchronous DNS resolver library by FFI, all threads of Haskell are blocked on non-threaded RTS. If the threaded RTS is used, forkProcess kills the IO thread. With the threaded RTS of at least GHC 6.10.4, we cannot make our program as a daemon nor use pre-fork mechanism. Thus, I decided to implement DNS resolver only with non-blocking Haskell functions. I use a *connected* UDP socket like this: proto <- getProtocolNumber "udp" let hints = defaultHints { addrFlags = [AI_ADDRCONFIG, AI_NUMERICHOST, AI_PASSIVE] , addrSocketType = Datagram , addrProtocol = proto } a:_ <- getAddrInfo (Just hints) (Just "An IP address of DNS server") (Just "domain") sock <- socket (addrFamily a) (addrSocketType a) (addrProtocol a) connect sock (addrAddress a) h <- socketToHandle sock ReadWriteMode hSetBuffering h NoBuffering hSetBinaryMode h True If my understating is correct, I cannot use recvFrom since it calls recvfrom() with FFI. So, I use socketToHandle to translate a socket to a handle. Since the handle is associated with UDP, the entire data size should be known when a UDP packet arrived. But I cannot find a way to know data size. (I want a function like hFileSize.) Note that hGetContents blocks. Without data size in advance, a program to handle network protocols on UDP becomes quite dirty or sometime cannot be implemented. So, please tell me how to know data size associated with a handler of UDP? --Kazu

2 2

Assembler errors when compiling nofib benchmarks with -optc-g
by Henry DeYoung 03 Nov '09

03 Nov '09

Hi, I am working with another grad student on a course project on cache behavior of GHC programs. The first part of this project is to reproduce some of the measurements from Nethercote and Mycroft's "The Cache Behavior of Large Lazy Functional Programs on Stock Hardware". We've decided to use oprofile to sample cache misses recorded by the performance counters. To get reasonable information out of oprofile, I'd like to compile the nofib benchmarks via C with export of debugging symbols. As a first step toward this, I've changed the NoFibHcOpts variable in nofib/mk/boilerplate.mk to be: NoFibHcOpts = -O -fvia-C -pgmc gcc -optc-g However, when I do make in the nofib/real/compress directory, for example, I get the following error message: ==nofib== compress: time to compile BinConv follows... /usr0/software/ghc-6.10.1/inplace/bin/ghc-stage2 -H32m -O -O -fvia-C -pgmc gcc -optc-g -Rghc-timing -H32m -hisuf hi -c BinCon v.hs -o BinConv.o <<ghc: 83082120 bytes, 8 GCs, 5163477/9786528 avg/max bytes residency (3 samples), 33M in use, 0.00 INIT (0.00 elapsed), 0.14 MUT (1.25 elapsed), 0.10 GC (0.12 elapsed) :ghc>> 1.27user 0.12system 0:01.39elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+21251minor)pagefaults 0swaps ==nofib== compress: size of BinConv.o follows... text data bss dec hex filename 6677 192 8 6877 1add BinConv.o ==nofib== compress: time to compile BinTest follows... /usr0/software/ghc-6.10.1/inplace/bin/ghc-stage2 -H32m -O -O -fvia-C -pgmc gcc -optc-g -Rghc-timing -H32m -hisuf hi -c BinTes t.hs -o BinTest.o /tmp/ghc14909_0/ghc14909_0.s: Assembler messages: /tmp/ghc14909_0/ghc14909_0.s:54:0: Error: unassigned file number 1 /tmp/ghc14909_0/ghc14909_0.s:54:0: Error: junk at end of line, first unrecognized character is `0' /tmp/ghc14909_0/ghc14909_0.s:56:0: Error: unassigned file number 1 /tmp/ghc14909_0/ghc14909_0.s:56:0: Error: junk at end of line, first unrecognized character is `0' /tmp/ghc14909_0/ghc14909_0.s:57:0: Error: unassigned file number 1 /tmp/ghc14909_0/ghc14909_0.s:57:0: Error: junk at end of line, first unrecognized character is `0' /tmp/ghc14909_0/ghc14909_0.s:61:0: Error: unassigned file number 1 /tmp/ghc14909_0/ghc14909_0.s:61:0: Error: junk at end of line, first unrecognized character is `0' etc... Curiously, if I remove the -optc-g flag, but still use -fvia-C and -pgmc gcc, everything works fine. Do you have any ideas what might be causing these errors? Is there a fix or workaround to get the C compiler to export debugging symbols? Second, it appears that a make with -fvia-C -pgmc gcc removes the C source after it has been compiled. Is there a way to preserve this source so that it can be annotated line by line using oprofile? I apologize if these questions are rudimentary; this is my first experience with GHC and nofib. Also, if these questions should be directed toward a different mailing list, please let me know. Thanks for any help you can give with this! Henry

3 4

array-0.2.0.0 doesn't build with 6.12rc1
by Ganesh Sittampalam 02 Nov '09

02 Nov '09

[ 6 of 10] Compiling Data.Array.IO ( Data/Array/IO.hs, dist/build/Data/Array/IO.o ) Data/Array/IO.hs:73:13: `haFD' is not a (visible) field of constructor `Handle__' Data/Array/IO.hs:73:22: `haBuffer' is not a (visible) field of constructor `Handle__' Data/Array/IO.hs:73:36: `haIsStream' is not a (visible) field of constructor `Handle__' Data/Array/IO.hs:74:5: Not in scope: data constructor `Buffer' Data/Array/IO.hs:74:13: `bufBuf' is not a (visible) field of constructor `Buffer' Data/Array/IO.hs:74:25: `bufWPtr' is not a (visible) field of constructor `Buffer' Data/Array/IO.hs:74:36: `bufRPtr' is not a (visible) field of constructor `Buffer' Data/Array/IO.hs:75:4: Not in scope: `bufferEmpty' Data/Array/IO.hs:82:24: `bufWPtr' is not a (visible) constructor field name Data/Array/IO.hs:82:35: `bufRPtr' is not a (visible) constructor field name Data/Array/IO.hs:86:24: `bufRPtr' is not a (visible) constructor field name Data/Array/IO.hs:95:27: Not in scope: type constructor or class `RawBuffer' Data/Array/IO.hs:101:10: Not in scope: `readRawBuffer' Data/Array/IO.hs:125:22: `haFD' is not a (visible) field of constructor `Handle__' Data/Array/IO.hs:125:31: `haBuffer' is not a (visible) field of constructor `Handle__' Data/Array/IO.hs:125:45: `haIsStream' is not a (visible) field of constructor `Handle__' Data/Array/IO.hs:127:18: Not in scope: data constructor `Buffer' Data/Array/IO.hs:127:26: `bufBuf' is not a (visible) field of constructor `Buffer' Data/Array/IO.hs:127:42: `bufWPtr' is not a (visible) field of constructor `Buffer' Data/Array/IO.hs:127:53: `bufSize' is not a (visible) field of constructor `Buffer' Data/Array/IO.hs:135:30: `bufWPtr' is not a (visible) constructor field name Data/Array/IO.hs:142:7: Not in scope: data constructor `Buffer' Data/Array/IO.hs:142:15: `bufBuf' is not a (visible) field of constructor `Buffer' Data/Array/IO.hs:142:27: `bufState' is not a (visible) field of constructor `Buffer' Data/Array/IO.hs:142:36: Not in scope: data constructor `WriteBuffer' Data/Array/IO.hs:143:8: `bufRPtr' is not a (visible) field of constructor `Buffer' Data/Array/IO.hs:143:19: `bufWPtr' is not a (visible) field of constructor `Buffer' Data/Array/IO.hs:143:34: `bufSize' is not a (visible) field of constructor `Buffer' Data/Array/IO.hs:151:22: Not in scope: type constructor or class `RawBuffer' Data/Array/IO.hs:151:43: Not in scope: type constructor or class `RawBuffer' Data/Array/IO.hs:153:22: Not in scope: type constructor or class `RawBuffer' Data/Array/IO.hs:153:35: Not in scope: type constructor or class `RawBuffer'

5 5

6.12.1 release
by Simon Marlow 02 Nov '09

02 Nov '09

The current dilemma we're facing with the 6.12.1 release is this: cabal-install still needs to be ported to the new version of Cabal, Duncan is snowed under and doesn't have time to work on it, but without cabal-install people can't easily test 6.12.1 RC and we can't test it with Hackage. We've come to rely on cabal-install quite a lot. So, one option is just to release 6.12.1 as is, with the caveat that cabal-install doesn't work, and large portions of Hackage probably do not work (but we don't know what exactly). The platform isn't due to release with GHC 6.12.x until February 2010, and by then we could make a 6.12.2 to fix any problems that we discover when cabal-install is working. One potential problem is that having made the 6.12.1 release we wouldn't be able to make any further API changes, only bug fixes. Or, we could just make a 6.12.1 RC2, and advertise it with the same caveats, putting out 6.12.1 when cabal-install works and we've had a chance to see the state of Hackage and alert package authors. Simon and I favour the RC2 option. What do others think? Cheers, Simon

7 9

Re: Type checker's expected and inferred types (reformatted)
by John Lato 31 Oct '09

31 Oct '09

> From: Isaac Dupree <ml(a)isaac.cedarswampstudios.org> > David Menendez wrote: >> On Sun, Oct 25, 2009 at 1:37 PM, Isaac Dupree >> <ml(a)isaac.cedarswampstudios.org> wrote: >>> David Menendez wrote: >>>> The expected type is what the context wants (it's *ex*ternal). The >>>> inferred type is what the expression itself has (it's *in*ternal). >>>> >>>> So inferring the type Maybe () for bar seems wrong. >>> well, maybe GHC just gets it wrong enough of the time, that I got confused. >>> >>> Or maybe ... When there are bound variables interacting, on the inside and >>> outside, it gets confusing. >>> >>> >>> ghci: >>> Prelude> \x -> (3+x) + (length x) >>> >>> <interactive>:1:15: >>> Couldn't match expected type `[a]' against inferred type `Int' >>> In the second argument of `(+)', namely `(length x)' >>> In the expression: (3 + x) + (length x) >>> In the expression: \ x -> (3 + x) + (length x) >>> >>> Your explanation of "expected" and "inferred" could make sense to me if the >>> error message followed the "Couldn't match" line with, instead, >>> "In the first argument of `length', namely `x'" >>> because 'length' gives the context of expected list-type, but we've found >>> out from elsewhere (a vague word) that 'x' needs to have type Int. >> >> This had me confused for a while, but I think I've worked out what's >> happening. (+) is polymorphic, ... > > Oh darn, it sounds like you're right. And polymorphism is so common. I > just came up with that example randomly as the first nontrivial > type-error-with-a-lambda I could think of... I think this is a great example of why the current type errors are not as helpful as they could be. The code where the type checker determines 'x' has type [a] is several steps removed from where the error arises. This is how I understand this process (I've probably left out some details): 1. checker infers x :: [a] from 'length x' 2. checker infers (3 + x) :: [a] from (+) and step 1 3. checker infers the second (+) :: [a] -> [a] -> [a] from step 2 4. conflict - checker expects (length x) :: [a] from step 3 and infers (length x) :: Int from definition of 'length'. Even with this simple example the error message given doesn't directly point to the problem. I don't think it's uncommon for there to be more steps in practice. I frequently find myself adding explicit type signatures to let-bound functions to debug these. This is a pain because it also usually involves enabling ScopedTypeVariables. I personally would find it useful if error messages showed the sequence of how the type checker determined the given context. Especially if it would also do so for infinite type errors, which don't provide much useful information to me. Cheers, John

3 3