February 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

ANNOUNCE: GHC 6.8.3 Release Candidate
by Ian Lynagh 23 Sep '09

23 Sep '09

We are pleased to announce the Release Candidate phase for GHC 6.8.3. Snapshots beginning with 6.8.2.20080527 are release candidates for 6.8.3 You can download snapshots from here: http://www.haskell.org/ghc/dist/stable/dist/ Right now we have the source bundles: http://www.haskell.org/ghc/dist/stable/dist/ghc-6.8.2.20080527-src.tar.bz2 http://www.haskell.org/ghc/dist/stable/dist/ghc-6.8.2.20080527-src-extralib… Only the first of these is necessary. The "extralibs" package contains various extra packages that are often supplied with GHC - unpack the extralibs tarball on top of the source tree to add them, and they will be included in the build automatically. There is also currently an installer for i386/Windows and binary distributions for x86_64/Linux and i386/Linux. More may appear later. Please test as much as possible; bugs are much cheaper if we find them before the release! We expect to release in a few days, assuming no major issues are discovered. Thanks Ian, on behalf of the GHC team

8 13

Linking and constants problems with OpenAL under Windows
by Jared 02 May '09

02 May '09

The OpenAL binding's wiki page directs questions to Haskell-Cafe, but the more serious of my problems seems to be with GHC. My platform is GHC 6.10.1 under Windows XP. This post boils down to two questions. First, why would GHCi and GHC look for different symbol names when linking, and second, has anybody had any success working with the OpenAL binding on Windows? If I write a program that uses Sound.OpenAL, I can load and run it in GHCi. If I try to compile the same program with ghc --make -lopenal32 audio.hs, I get a raft of errors like this: Linking audio.exe ... C:\Program Files\Haskell\OpenAL-1.3.1.1\ghc-6.10.1/libHSOpenAL-1.3.1.1.a(BufferInternal.o):fake:(.text+0x5d): undefined reference to `alIsBuffer' C:\Program Files\Haskell\OpenAL-1.3.1.1\ghc-6.10.1/libHSOpenAL-1.3.1.1.a(Context.o):fake:(.text+0x7d): undefined reference to `alcGetContextsDevice' C:\Program Files\Haskell\OpenAL-1.3.1.1\ghc-6.10.1/libHSOpenAL-1.3.1.1.a(Context.o):fake:(.text+0xcd): undefined reference to `alcMakeContextCurrent' The names do not exist in openal32.lib. They should all be preceded by an underscore. GHC does the same thing if I convert the .lib file to a .a file. But why would GHCi do the right thing and GHC do the wrong thing? Am I missing a command line switch? I manually changed configure and configure.ac, per the patches (why weren't those applied to the library in Hackage?) to use ccall since OpenAL uses ccall instead of stdcall. Was there another change I should have made? The other problem is that several routines don't work properly because the constants don't get fixed up correctly during the build process. For example, the function marshalFormat in Sound.OpenAL.AL.Format should return 0x1100 when given Word8 as a parameter. It returns -1 instead; the code tells it to, but I assume some sed-like command was supposed to patch that with the right value. Has anybody had any luck getting this to work?

2 1

Loop unrolling + fusion ?
by Don Stewart 28 Mar '09

28 Mar '09

Hey guys, We have nice fusion frameworks now. E.g. stream fusion on uvector, http://hackage.haskell.org/cgi-bin/hackage-scripts/package/uvector Takes something like this: import Data.Array.Vector import Data.Bits main = print . productU . mapU (*2) . mapU (`shiftL` 2) $ replicateU (100000000 :: Int) (5::Int) and turns it into a loop like this: $wfold :: Int# -> Int# -> Int# $wfold = \ (ww_sWX :: Int#) (ww1_sX1 :: Int#) -> case ww1_sX1 of wild_B1 { __DEFAULT -> $wfold (*# ww_sWX 40) (+# wild_B1 1); 100000000 -> ww_sWX } Now, that's fine in my book. Going via -fasm, we get: Main_zdwfold_info: .LcYt: movq %rdi,%rax cmpq $100000000,%rax jne .LcYx movq %rsi,%rbx jmp *(%rbp) .LcYx: incq %rax imulq $40,%rsi movq %rax,%rdi jmp Main_zdwfold_info Ok: $ time ./product 0 ./product 0.31s user 0.00s system 96% cpu 0.316 total Going via C, however, we get: Main_zdwfold_info: cmpq $100000000, %rdi je .L6 .L2: leaq (%rsi,%rsi,4), %rax leaq 1(%rdi), %rdi leaq 0(,%rax,8), %rsi jmp Main_zdwfold_info Nice! $ time ./product 0 ./product 0.19s user 0.00s system 97% cpu 0.197 total So now, since we've gone to such effort to produce a tiny loop like, this, can't we unroll it just a little? Sadly, my attempts to get GCC to trigger its loop unroller on this guy haven't succeeded. -funroll-loops and -funroll-all-loops doesn't touch it, Anyone think of a way to apply Claus' TH unroller, or somehow convince GCC it is worth unrolling this guy, so we get the win of both aggressive high level fusion, and aggressive low level loop optimisations? -- Don

9 33

Re: finally part run twice on Ctrl-C
by Philip K.F. Hölzenspies 09 Mar '09

09 Mar '09

> I've got the following code: > > import Control.Exception > import System.Cmd > main = system "sleep 1m" `finally` putStrLn "goodbye" > > When compiled with GHC 6.10.1.20090225, if I hit Ctrl-C during the > sleep, I get the goodbye printed twice. If I leave evaluation to > finish normally I get goodbye once. Is this a bug? Dear Neil, et al. Just to let you know; I tried it on the release version of 6.10.1 and it worked as expected (first run, I waited; second I pressed Ctrl-C): *Test> main goodbye ExitSuccess *Test> main goodbye ExitFailure 2 *Test> If not coming from system differences, the bug should sit in recent code. Regards, Philip

2 3

Warning about unrecognised pragma
by Colin Paul Adams 07 Mar '09

07 Mar '09

I am getting messages: Board_representation.hs:407:0: Unrecognised pragma Board_representation.hs:442:0: Unrecognised pragma Board_representation.hs:458:0: Unrecognised pragma etc. (GHC 6.10.1) I looked into the documentation to see how to supress these warnings (prefereably for the particular pragma concerned), but I found (from 8.13): any pragma encountered with an unrecognised word is (silently) ignored. -- Colin Adams Preston Lancashire

3 4

my experience with ghci debugger extensions
by Peter Hercek 01 Mar '09

01 Mar '09

Hi users of ghci debugger, This post is going to be a bit longer. Here are few cookies to motivate you to go on: * you will probably like it more than printf debugging for a lot of cases * it can provide a way of implementing Claus Reinke's idea of breakpoints with a list of identifiers which should be available at breakpoint location and doing it without recompilation; here is the link to Claus' message: http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/15900 * it gives some idea to ghc team about importance of ghci debugger related tickets (and whether to implement them just the way they were proposed) A note to ghc developers: Stepping program in ghci debugger sometimes purges top level bindings and sometimes not. Not sure this is a bug or feature (whether there is some logic in it). I do not have a simple example when it purges the bindings. But I did not really look for one. I would probably post later, but some ghci bugs and missing features are badly limiting my progress. There is not much more I can think of to investigate. Maybe somebody will have better ideas how to solve the obstacles I'm hitting. I'm also posting with hope that people will find this interesting and ghc team will fix some of the critical bugs and adds the most critical features, especially if somebody will not have better debugging tips. You can get my extensions here: http://www.hck.sk/users/peter/pub/ghciext-0.1.tar.gz The extensions are not in a single .ghci file now. The new .ghci file needs to install a library. The reason is that without the library it is not manageable any more. And here are arch linux packaging instructions for my custom ghc (if you are an arch linux user just download and run makepkg :) ): http://www.hck.sk/users/peter/pub/ghc-custom-6.10.1.tar.gz The custom ghc is just the same one as ghc 6.10.1 with two more patches: t2740.patch and loglocal.patch. The first one fixes ticket 2740 and you will get it in 6.10.2. The second one adds :loglocal command to ghci. You can extract the patches from the tar file. If you already read ghci scripting tutorial from Claus Reinke then you will know how to customize ghciext (that is if you would feel like doing so). The tutorial is here: http://www.haskell.org/pipermail/haskell-cafe/2007-September/032260.html Here is the list of custom commands in ghciext package: :defs -- list user-defined commands :. <file> -- source commands from <file> :redir <var> <cmd>... -- execute <cmd> redirecting stdout to <var> :grep <pat> <cmd>... -- filter lines matching <pat> from <cmd> output :* <count> <cmd>... -- run <cmd> <count> times :x <cmd>... -- run <cmd> with stdout suppressed :bp <bpArgs> -- put breakpoint at location <bpArgs> (adds hit count) :inject <cc> <c> <sc> <b> -- at location <b> execute <c> if <cc>, and stop if <sc> :monitor ["<c>"] <vs> <b> -- show comma separated variables at location <b> if <c> :watch <cond> <bpArgs> -- break at location <bpArgs> when <cond> is True :count (_|<N>) [<bpArgs>] -- count/query/stop execution at location <bpArgs> :find <var> <cmd>... -- step with <cmd> until <var> is found :findex <str> <cmd>... -- step with <cmd> until <str> is found :next [lazy] -- step over; lazy version forces only the top constructor :xout -- redirect ghci stdout to /dev/null :out -- redirect ghci stdout back to console :defs, :., :redir, :grep, are the same as the commands in Claus' tutorial. The only differences I recall now are: * grep pattern can be in quotation marks (easier search for spaces) * grep merges :browse output more nicely * redir can accept :step, :steplocal etc; i.e. also the commands which sometimes remove top level bindings * the commands do not pollute top level bindings so much The rest will describe my custom commands and now they relate to tickets in ghci track. If you want to check the tickets mentioned here then the most easy way is probably selecting them from this list: http://hackage.haskell.org/trac/ghc/search?q=phercek&noquickjump=1&ticket=on The initial big problem was how to limit the amount of information ghci debugger spits at you when breakpoints with custom scripts are used. This is also mentioned in forth point of the "unknown" section of ticket #1377: /We can disable a breakpoint with ":set stop N :continue", but this still prints out the breakpoint info when we stop. Should we print the info only if there were no commands?/ So I say: yes do it! Just disable any ghci output related to a breakpoint when the breakpoint has a custom code attached. We can disable the output ourselves, but then we disable all the output (including the output of the debugged program). People who are debugging console applications are busted (especially if the applications are interactive). This is not an issue for me since my application is not using console almost at all. I'm solving the problem by prefixing commands like /:main/ and /:continue /with my command /:x/. This makes output by default disabled and ghciExt enables it just before a breakpoint code is run. If the breakpoint continues execution it disables it again. If the debugged function finishes the output is enabled by /:x/ itself. A small problem happens when you forget to use /:x/ e.g. with your /:main/. Then you do not get a prompt when the program finishes. It's time to notice it and use /:out/ to switch it on. This is the only minor disadvantage for a gui application debugging. /:xout /in not that useful (it is mostly used internally by /:x/). It could be a hidden command (i.e. not registered in defs). Now when we have ghci "muted" we can get to real goodies: /:monitor/, /:watch/, and /:count/. If you like printf debugging, then /:monitor/ can help you. It can monitor only free variables in the selected expression (on which a breakpoint is hit) but that was always enough for me during debug sessions I had. Write a script file (lets say it is named *ghciInit* (I'll also call it this way later on in this text)) which is like this example: /:monitor var1,var2 ModuleName 23 :monitor var3 ModuleName 40 :x :main mainArgument/ Then open ghci with your program and run *:. ghciInit* And you will get nice log like this: /(0): var1 = <value01> var2 = <value02> (1): var3 = <value03> (0): var1 = <value11> var2 = <value12> (1): var3 = <value13> ... etc/ Moreover /:monitor/ allows condition in quotation marks to be specified as the first argument. If you do it then the variable values will be printed only when the condition is True. Of course the condition can contain only free variables in the selected expression. Mostly it is not a problem. /:watch/ is a conditional breakpoint which stops when the specified condition is True. /:count/ has 3 forms: /:count _ ModuleName 23/ This never breaks just counts number of times the execution reached position ModuleName 23 /:count 5 ModuleNmae 23/ This breaks when we reach position ModuleName 23 fifth time /:count 0/ This tells how many times breakpoint number 0 was hit (it can report the number of hits for any breakpoint created with /:bp/, /:inject/, /:monitor/, /:watch/, and /:count/). The first form of /:count/ is interesting when you want to stop earlier than something bad happens so that you can see why the bad think happened. Put the first form of /:count/ at the start of the function with the bug and then put a break in the function which is hit when the bad think happens maybe with /:watch/. When you stop at the bug place, check hit count at the start of the function. Add the hit count in your /:count/ breakpoint in your *ghciInt* file restart and you can use /:steplocal/ or /:loglocal/ to find out what went wrong. /:loglocal/ is implemented directly in ghc source code. It does exactly the same as /:steplocal/ but makes sure that the trace history does not contain anything outside of the function we step with /:steplocal/. The problem is that /:steplocal/ works like the code was traced while it is executing. Mostly the result is that your trace history is loaded with crap outside of the scope you are interested in. I'll return to /:loglocal/ later again. /:inject/ is there when you need something special (/:monitor/, /:watch/, and /:count/ are implemented with something very like /:inject/). E.g. when you want to do monitoring of a value but do not want the associated breakpoint number printed. /:find/ and /:findex/ are there primary to search trace history. /:find var1 :back/ will find the variable var1 in your trace history by back stepping it /:find var1 :step/ will single step forward till variable var1 is in the list of free variables /:findex BL/Logic.hs:23 :loglocal/ will fill in your trace history will all the local breakpoints till location BL/Logic.hs:23 is hit. Having the trace history filled in with the right stuff is useful for checking out why you got bad results later. Now lets return to Claus' idea of breakpoints with a list of identifiers which should be available at the breakpoint location. You can make sure the identifiers are available with the first form of /:count/. It never stops but it puts records to the trace history. So the trace history will contain free variables at the locations where you put /:count/. This will be even more useful when automatic search of trace history is built in (see ticket #2737). So a weaker form of Claus' idea can be implemented by carefully selecting what should bet to the trace history. Why a weaker form only? Well, in some cases, the variable instances in trace log may not be the expected ones (they may be from a different lexical scope). Experience with my code indicates this should be rare. /:next/ is an idea how to implement a kind of step over. That is if by step over you mean something else than steplocal. The non-lazy form of /:next/ forces _result and does a /:step/. The lazy form forces only the top level constructor of _result before the step. Hey, I even had a case when it worked just like I expected. But typically it does not work because of bug #1531. _result is not correctly bound to the result of selected expression in most of the practical cases. This bug is also critical for all the forms of conditional breakpoints. It would be cool if we could specify the condition based on _result or some part of it. The implementation of ghciExt conditional breakpoints would need to be extended to support conditions on _result (in particular the breakpoint would need to be disabled during the condition execution) but that is easy to do. Even more worrying thing about bug #1531 is that it has the milestone set to _|_. It is easy to add /:enable/ and /:disable/ to support enabling and disabling breakpoints. I just did not need it yet. Here is how a GhciExt breakpoint looks like: *Main> :show breaks [0] Main a.hs:4:2-8 ":cmd return$GhciExt.getStopCode 0 (True) "putStr \"(0): \"\n:force x" "False"" *Main> Just replace getStopCode with getDisabledStopCode and you have it disabled. Return back to enable. Yeah, and implement getDisabledStopCode which will just continue. I added :/loglocal/ mostly to simulate how /:tracelocal/ in ticket #2737 would help. I was also trying how full tracing is helping. In both cases the answer is: full tracing almost never helps. /:tracelocal/ from ticket #2737 as proposed originally would rarely help. The problem is that trace log gets overwhelmed with crap when we cannot control what can be saved in it and what cannot be saved. My idea is that user should be able to specify what can go in it and also what should not go in it. Here is an alternative solution to the ones I proposed in tickets #2737 and #2946. I think this one would be best. The command to control the tracing should look like: -- should everything be traced? :set trace (True|False) -- scopes which should be traced (or should not be traced when ! is present) :set trace ( (!)? scopeid )* -- add/remove individual scopeids to/from the trace specification :set trace (+|-) (!)? scopeid where scopeid = ( conid . )* ( varid . )* varid Notice how scopeid looks. It can have a sequence of varids at the end. The reason is so that user can leave out a scope of a function which is defined in a where clause. The scope specification is similar to the proposal in ticket #3000. E.g. for this code: fn s = 'a' : add s where add = (++"z") it could look like :set trace Main.fn !Main.fn.add meaning trace whole scope of *fn* but not the stuff in the scope of *add. *Order should not be important, requests for not tracing should have precedence before requests to trace. The scopes which we want typically exclude are the ones which contain loops. The loop content often fills in the trace log forcing the interesting stuff out of it. It is better to investigate functions with loops separately in nested context. Notice that there is a bit difference between this proposal of controlling trace content and the one in ticket #2737. #2737 assumes usage of breakpoint arguments to specify a scope. The breakpoint arguments give an ability to define scopes at finer level but there is no option to define exclude scopes which I find important now. The summary is: Trace log is as useful as much you can control what can get in it. The :trace command looks to me like an error. It is better to control it by allowing/disallowing scopes. I also changed my opinion a bit about ticket #2945. :mergetrace would be better than global trace history. Being able to investigate something separately in a nested context is useful. If I should order the ghci debugger related tickets then the order would be like (more important first): #1531 (_result can get bound to the wrong value in a breakpoint) #2737 and #2946 (add :tracelocal to ghci debugger... and add command :mergetrace...) #3000 (:break command should recognize also nonexported top level symbols...) #2803 (bring full top level of a module in scope when a breakpoint is hit in the ...) #1377 (the task: "We should print breakpoint related info only if breakpoint has no commands set") but people debugging interactive console applications would like to have this one the very top; *IIRC* this may be easy to do, looks like all the printing is done in one function (something like afterCmd???); also #2950 looked like trivial to do (like 15 mins without the compile time???) And the last thing: my first time experiences hacking in the /:loglocal/ into ghc. I cannot tell much, I spend with it only one long Sunday afternoon, but here are my two points: * I needed to extend ghc interface. The type of function GHC.resume changed from: resume :: GhcMonad m => SingleStep -> m RunResult to: resume :: GhcMonad m => (SrcSpan->Bool) -> SingleStep -> m RunResult ... plus the corresponding implementation change. The added argument is a filtering function to limit source spans which can recorded in the trace history. * It would be cool if ghci has its own dir in the souce tree where only the ghci source files are. It would encourage people to hack it more since it would be easier to maintain private patches and merging upstream. It would be also easier to make sure one modifies only ghci source code so that it works with other ghc releases. Hopefully this helps somebody, Peter.

7 18

Int vs Word performance?
by Claus Reinke 01 Mar '09

01 Mar '09

Looking at prelude/PrelRules.hs has reminded me of an old conundrum: if I switch from Int to Word, should I expect any performance differences? A while ago, I needed lots of fairly small positive numbers, together with a small number of flags for each, so I thought I'd switch from Int to Word, and map the flags to bits. But the performance dropped so drastically that I went back to Int, slightly complicating the bitmaps. I didn't expect that, and I can't see any builtin rules for Int that would have no Word counterpart. Here is a trivial example with drastic difference between T = Int and T = Word (~2.5x here): main = print $ foldl' (+) 0 [1..100000000::T] What am I missing here? Also, in the real code I ended up seeing things like this in the -ddump-simpl output for the bit-fiddling code: GHC.Prim.word2Int# (GHC.Prim.and# (GHC.Prim.int2Word# wild13_XbE) (GHC.Prim.int2Word# y#_a4EZ)) Is that likely to cost me a lot or are these conversions cheap? Claus

5 12

ghc crashes on strange foreign import
by Ben Franksen 27 Feb '09

27 Feb '09

This is the code: {-# OPTIONS -fglasgow-exts #-} import Foreign type X u = Ptr () foreign import ccall bla :: (forall u. X u) -> IO () I know of course that I must not use fancy types in foreign imports. I forgot for a moment and instead of an error message got: ben@sarun> ghci Bug3 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. [1 of 1] Compiling Main ( Bug3.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-unknown-linux): unboxArg: Bug3.hs:4:0-51 forall u{tv aht} [tv]. main:Main.X{tc rhp} u{tv aht} [tv] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Cheers Ben

1 0

Suggestion for bang patterns documentation
by Brian Bloniarz 27 Feb '09

27 Feb '09

I got confused by the GHC documentation recently, I was wondering how it could be improved. From: http://www.haskell.org/ghc/docs/latest/html/users_guide/bang-patterns.html > A bang only really has an effect if it precedes a variable or wild-card pattern: > f3 !(x,y) = [x,y] > f4 (x,y) = [x,y] > Here, f3 and f4 are identical; putting a bang before a pattern that > forces evaluation anyway does nothing. The first sentence is true, but only in settings where the pattern is being evaluated eagerly -- the bang in: > f3 a = let !(x,y) = a in [1,x,y] > f4 a = let (x,y) = a in [1,x,y] has an effect. The first time I read this, I took the first sentence to be a unqualified truth and ended up thinking that !(x,y) was equivalent to (x,y) everywhere. Stuff that comes later actually clarifies this, but I missed it. What about making the distinction clear upfront? Something like: > A bang in an eager pattern match only really has an effect if it precedes a variable > or wild-card pattern: > f3 !(x,y) = [x,y] > f4 (x,y) = [x,y] > Because f4 _|_ will force the evaluation of the pattern match anyway, f3 and f4 > are identical; the bang does nothing. It also might be a good idea to immediately follow this with the let/where usage: > A bang can also preceed a let/where binding to make the pattern match strict. For example: > let ![x,y] = e in b > is a strict pattern... (in the existing docs, let comes a bit later): Just a thought. Hopefully someone can come up with a better way of wording what I'm getting at. Thanks, -Brian _________________________________________________________________ Windows Live™ Hotmail®…more than just e-mail. http://windowslive.com/howitworks?ocid=TXT_TAGLM_WL_t2_hm_justgotbetter_how…

3 5