December 2008 - 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 22 Sep '09

22 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

length of module name affecting performance??
by Daniel Gorín 09 Feb '09

09 Feb '09

Hi While trying to see if I could make some code run faster I stumbled upon something that looks weird to me: 2x-3x performance loss when a module is renamed to a longer name! Here's what I see with the attached examples: #diff long-modname-ver.hs short-modname-ver.hs 2c2 < import VeryLongModuleName --- > import ShortM #diff VeryLongModuleName.hs ShortM.hs 1c1 < module VeryLongModuleName --- > module ShortM #ghc --make -O2 -Wall long-modname-ver.hs #ghc --make -O2 -Wall short-modname-ver.hs #time -p ./long-modname-ver > /dev/null real 55.90 user 55.17 sys 0.51 #time -p ./short-modname-ver > /dev/null real 22.23 user 21.97 sys 0.10 I'm using GHC 6.10.1 on OS X. Any ideas on what may be going on? Thanks Daniel

9 12

ghci debugger :trace command does not always extend trace history
by Peter Hercek 13 Jan '09

13 Jan '09

Hi, I expected ":trace expr" to always add data to the trace history but it does not do so for CAFs (which are not reduced yet). My point is that the command ":trace z" did not add anything to the trace history and I cannot check why value z is 2, because value of y is not in the trace history. Is this the expected behavior? If it is, how can I make ghci to extend the trace history when "forcing" variables? Peter. Here is the example: status:0 peter@metod [765] ~/tmp % cat a.hs test :: Int -> Int test x = let y = x+1 in let z = y+1 in z status:0 peter@metod [766] ~/tmp % ghci a.hs GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. [1 of 1] Compiling Main ( a.hs, interpreted ) Ok, modules loaded: Main. *Main> :break Main 5 Breakpoint 0 activated at a.hs:5:2 *Main> :trace test 0 Stopped at a.hs:5:2 _result :: Int = _ z :: Int = _ 4 let z = y+1 in 5 z 6 [a.hs:5:2] *Main> :back Logged breakpoint at a.hs:(2,0)-(5,2) _result :: Int 1 test :: Int -> Int 2 test x = 3 let y = x+1 in 4 let z = y+1 in 5 z 6 [-1: a.hs:(2,0)-(5,2)] *Main> :back no more logged breakpoints [-1: a.hs:(2,0)-(5,2)] *Main> :forward Stopped at a.hs:5:2 _result :: Int z :: Int 4 let z = y+1 in 5 z 6 [a.hs:5:2] *Main> :trace z 2 [a.hs:5:2] *Main> :back Logged breakpoint at a.hs:(2,0)-(5,2) _result :: Int 1 test :: Int -> Int 2 test x = 3 let y = x+1 in 4 let z = y+1 in 5 z 6 [-1: a.hs:(2,0)-(5,2)] *Main> y <interactive>:1:0: Not in scope: `y' [-1: a.hs:(2,0)-(5,2)] *Main> :back no more logged breakpoints [-1: a.hs:(2,0)-(5,2)] *Main> :forward Stopped at a.hs:5:2 _result :: Int z :: Int 4 let z = y+1 in 5 z 6 [a.hs:5:2] *Main> z 2 [a.hs:5:2] *Main> y <interactive>:1:0: Not in scope: `y' [a.hs:5:2] *Main> :quit Leaving GHCi. status:0 peter@metod [767] ~/tmp %

2 4

Build system idea
by Simon Marlow 10 Jan '09

10 Jan '09

Simon PJ and I had a talk about the build system earlier today, I thought I'd float the idea we discussed (I should admit that the idea was mine, lest Simon PJ think I'm attributing bad ideas to him :-). This is not completely thought through, but I'm pretty sure a solution exists along these lines that would improve things for us. Ok, the starting point is this: - Cabal has code to generate Makefiles. Almost nobody uses it except for the GHC build system. It essentially duplicates the build system for compiling Haskell source (but not for installation, haddocking, registration, configuration, etc.) - Cabal is a library I propose we do this: - Extract the code from Cabal that generates Makefiles, and treat it as part of the GHC build system. Rather than generating a Makefile complete with build rules, we generate a Makefile that just has the package-specific metadata (list of modules, etc.), and put the code to actually build the package in the GHC build system. This means we still get to use 'make', we still get to use the .cabal files as metadata, but the build system is more private to GHC, more extensible, and hopefully more understandable and modifiable. We can express dependencies that Cabal currently doesn't know about. It would let us avoid the current uncomfortable situation where we have to feed all kinds of configuration information from the GHC build system into Cabal - Cabal would be essentially just a mechanism for translating the .cabal file into Makefile bindings and package metadata for ghc-pkg. There will undoubtedly be some sticking points where we have to tradeoff duplicating things from Cabal against re-using parts of Cabal which might require modifying Cabal itself. For instance, we could use Cabal for installation, but that means that our build system has to leave everything in the places that Cabal's installation code expects, so it might be more feasible to do installation ourselves, but that means duplicating parts of Cabal. It will probably mean that we have a tighter dependency on Cabal, because we use it as a library rather than a black box; but hopefully we can keep our branch of Cabal more stable and not have to update it so often. Anyway, this is an idea that I think is interesting. Obviously it needs a lot more fleshing out to be a real proposal, but I'm interested in whether anyone thinks this idea is worth persuing, or whether there are better alternatives. Cheers, Simon

16 49

GADT Strangeness
by Dominic Steinitz 10 Jan '09

10 Jan '09

If I remove -XScopedTypeVariables from this http://hpaste.org/13230 then I get the following error message: > Asn1cTestNew.hs:55:27: > GADT pattern match in non-rigid context for `INTEGER' > Solution: add a type signature > In the pattern: INTEGER > In the definition of `referenceTypeAndValAux2': > referenceTypeAndValAux2 ns INTEGER x > = lhs ns <> text " = " <> text (show x) <> semi > Failed, modules loaded: Language.ASN1, ASNTYPE. At the very least the message is unhelpful. It was only by accident I decided to put in -XScopedTypeVariables. Can anyone offer an explanation as to what is happening? Dominic.

3 6

ghc 6.10.1 on freebsd 7 amd64 - ghci problems
by Markus Barenhoff 08 Jan '09

08 Jan '09

Hi! Because the ports seem not to get updated, I tried to compile ghc 6.10.1 under freebsd 7 on amd64 myself. For compiling I first used the ports ghc version (6.8.3) and then, in a second try I used the self build 6.10.1 to build it again. I added building of api docs with: $ echo "HADDOCK_DOCS = YES" >> mk/build.mk I configured it with a simple ./configure and not more options. The compiler seems to work well on both versions. But if i try to start ghci I get the following: ---- snip ---- $ ghci GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help ghc: Unable to mmap() for jump islands Loading package ghc-prim ... ghc: panic! (the 'impossible' happened) (GHC version 6.10.1 for x86_64-unknown-freebsd): loadObj: failed Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug ---- snip ---- It looks he has some kind of library loading problems? Any ideas? Thnx and regards Markus

3 13

Re: [reactive] Re: black hole detection and concurrency
by Bertram Felgenhauer 06 Jan '09

06 Jan '09

Peter Verswyvelen wrote: > I fail to understand this part of the code: > case fromException e of > Just ThreadKilled -> do > myThreadId >>= killThread > unblock (race a b) > > So the current thread gets killed synchronously, then then the race function > is evaluated again? The latter I don't get. Let's look at what happens when an asynchronous exception arrives. The current thread gets killed. It gets killed asynchronously; as far as the RTS knows, the exceptionit might happen inside a pure computation which may be accessible to other threads. This means that the RTS has to patch things up so that reentering the corresponding thunks continues the computation - because another thread might need the value later. It does that by traversing the stack and turning update frames into ap nodes on the heap, and linking the entered thunks to those using an indirection (again, see RaiseAsync.c for details). Now in fact, IO actions are indistinguishable from pure computations by the RTS, so this mechanism also makes IO actions resumable, in principle, if you can access the corresponding thunk somehow. Normally you can't - there is no reference to that thunk - but unsafePerformIO gives you that reference. So in the above example, the current thread gets killed. However, the IO action (suspended right before the 'unblock (race a b)') is still accessible through the unsafePerformIO thunk. When another thread enters that thunk, execution resumes at that point. It may also be the same thread if it caught the exception further down the stack and later enters the unsafePerformIO thunk again. I don't understand all the interactions here - I don't know why the code is racy in the parallel RTS. Bertram

6 6

unique identifiers as a separate library
by Sebastian Fischer 06 Jan '09

06 Jan '09

Hello, for a project I am using the libraries Unique, UniqSupply, and UniqFM from the package ghc. It seems odd to have a dependency on a whole compiler only in order to use its (highly efficient and, hence, preferred) implementation of unique identifiers. Would it be possible to put everything concerned with unique identifiers in GHC into a separate package on Hackage? This may also allow me to get a fix for <http://hackage.haskell.org/trac/ghc/ticket/2880 > without reinstalling GHC. Cheers, Sebastian

5 17

building HSQL MySQL on windows (Was: FFI imported function names)
by Daniil Elovkov 06 Jan '09

06 Jan '09

Ok, enough talking to myself :) If anybody ever wants to build hsql-mysql on windows and has the same problems as I had, here's how it should be done. The problem I had seemed to be that libmysql.dll uses stdcall, but names its functions without @<n> decoration. Thus, when linking a Haskell program against it, names with @<n> cannot be resolved. The solution is pretty much a hack. Somebody from the Ruby community used to run into the same problem, from the same situation -- namely building ruby mysql bindings. Here is the procedure one person suggests http://rubydotnetproxy.rubyforge.org/mysql_win.html It worked perfectly for me. Of course, with some cabal specifics, which is obviously not described in the above page. The solution was to create a def file listing the names which could not be resolved and creating a .a file based on the dll and this def file. 2008/12/24 Daniil Elovkov <daniil.elovkov(a)googlemail.com>: > Mm, actually I didn't change the calling convention ffi imports when I > thought I did. I tried to do it through defines... > > Well, by explicitly saying ccall I get the names without @<n> > decoration. And it all links well. But I get segault when I run the > code, which should mean that calling conventions didn't match. > > Actually I found some ramblings on the internet that there's something > wrong with libmysql.dll and libmysql.lib in this respect, but they > were from 2004. > > Thus the question: how do I link against a lib file in ghc? When I say > -lmysql on command line it strictly searches for dll and complains if > it's not found. Adding lib exlpicitly on the cmd line doesn't seem to > have any effect. > > Thanks > > > 2008/12/24 Daniil Elovkov <daniil.elovkov(a)googlemail.com>: >> Hello >> >> How is decided whether the name of imported function gets the ending >> of the form @4 in ghc? >> >> I'm having this problem on Windows trying to use HSQL MySQL on windows. >> >> I compile HSQL Oracle backend and I get names without that. It's ok. >> With HSQL MySQL I get names with that stuff. It prevents me from >> further linking to dll. Supplying in the ghc command-line the "lib" >> file where names have those marks doesn't have any effect. >> >> The linker says that fname@NN cannot be resolved. >> >> Can I control that? >> >> The ffi calling convention doesn't (and shouldn't as I understand) >> affect this. The only difference is that in the case of mysql the >> header file itself where functions are described marks it STDCALL. Is >> that the reason? >> >> Also I changed ffi import line from "hsmysql.h func" to just "func", >> to no avail. >> >> ghc 6.8.2 >> >> I'm lost. Please help. >> >> -- >> Daniil Elovkov >> > > > > -- > Daniil Elovkov > -- Daniil Elovkov

2 1