May 2010 - 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.12.3 Release Candidate 1
by Ian Lynagh 17 Jun '10

17 Jun '10

Hi all, We are pleased to announce the first release candidate for GHC 6.12.3: http://www.haskell.org/ghc/dist/6.12.3-rc1/ As well as the source tarball: ghc-6.12.2.20100521-src.tar.bz2 there are installers for Windows (i386) and OS X (i386), and binary distributions for x86_64/Linux and i386/Linux. 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

9 13

Re: ANNOUNCE: MonadCatchIO-foreign
by Antoine Latter 09 Jun '10

09 Jun '10

Hi GHC, Is there a reason that Foreign.Marshall.Array.allocaArray calls into allocaBytes instead of allocaBytesAligned? Since alloca needs the alignment, wouldn't allocaArray also need it? I'm not too up on how memory access is supposed to work, it was just something that jump out at me. Thanks, Antoine On Sun, May 30, 2010 at 7:10 PM, Antoine Latter <aslatter(a)gmail.com> wrote: > Hello Haskell, > > I'd like to announce a very small library in two flavors. > > The problem I'm trying to solve is that we have some capabilities for > writing functions which are polymorphic over monad but still use IO > capabilities - liftIO :: (IO a -> m a) from the packages transformers > and mtl. The packages[1,2] MonadCatchIO offer similar polymorphism for > the exception capabilities of the IO monad. > > The package MonadCatchIO-foreign offers similar polymorphism for the > following functions: > > alloca, allocaBytes, allocaArray, allocaArray0 and withForeignPtr. > > It's a small thing, but I don't see why it should be written twice. > > Links on hackage: > > http://hackage.haskell.org/package/MonadCatchIO-mtl-foreign > http://hackage.haskell.org/package/MonadCatchIO-transformers-foreign > > GitHub link: > > http://github.com/aslatter/MonadCatchIO-foreign > > Feedback, praise and adulation welcome. > > Antoine >

3 3

Re: ANNOUNCE: GHC 6.12.3 Release Candidate 1
by Ian Lynagh 31 May '10

31 May '10

On Mon, May 31, 2010 at 12:38:56PM +0100, Barney Stratford wrote: > > Any ideas? Have you tried running the testsuite, to see if you can find a small failing program? I'd try the ffi tests first, e.g.: cd testsuite/tests/ghc-regress/ffi make CLEANUP=1 SKIPWAY=ghci Thanks Ian

1 0

Memory use blowup with -O1 (versus -O0) in GHC 6.12.1/6.12.2
by Robert Greayer 25 May '10

25 May '10

Hi, I've encountered an interesting issue with GHC 6.12.1 and 2 in which a small program compiles quickly without using loads of memory with optimization turned off, but with optimization (-O1) turned on, GHC's memory usage becomes very high (and compilation takes much much longer). $ time ghc -c -O0 Tst.hs real 0m0.107s user 0m0.073s sys 0m0.035s $ time ghc -c -O1 Tst.hs real 0m38.605s user 0m36.669s sys 0m1.923s Memory used by GHC looks like it tops out at 3G (in the -O1 case). Constraining the heap size to 1G causes compilation to fail: $ ghc +RTS -M1g -RTS -c -O1 Tst.hs Heap exhausted; Current maximum heap size is 1073741824 bytes (1024 MB); use `+RTS -M<size>' to increase it. (whereas, without optimization, a heap of 16m is sufficient) The module being compiled is (probably deceptively) simple: module Tst where import Merge data Rec1 = Rec1 !Int mkRec1 v = mk $ merge v () where mk (Tagged i :* ()) = Rec1 i but the devil is in the details of 'merge' (attached) which merges heterogeneous lists of values, using a lot of type level programming with type families. Does this sound like an known, open issue? I was unable to find anything in GHC Trac that looked similar. Thanks, Rob

3 2

RE: [Haskell-cafe] Re: Data instance for a GADT
by Simon Peyton-Jones 25 May '10

25 May '10

There have been a couple of emails about Template Haskell support for · GADTs · View patterns · Reifying instances There’s a ticket for this already http://hackage.haskell.org/trac/ghc/ticket/3497 It’s mainly a library design question, in this case the design of the Template Haskell data types in Language.Haskell.TH.Syntax. It needs some motivated person to propose a design, get a consensus, and write some boilerplate code. Just use the standard libraries process An issue is the extent to which it’s ok to change the Template Haskell data types (and thereby break people’s code), but that’s something the interested parties can work out together. If you evolve a consensus design I’m more than happy to make it part of GHC. I just don’t want to drive the consensus building! Simon From: haskell-cafe-bounces(a)haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Ozgur Akgun Sent: 14 April 2010 10:53 To: Haskell cafe Subject: [Haskell-cafe] Re: Data instance for a GADT Seeing this old thread[1], I hope something happened towards enabling this. Does anybody know the current status about using TH on GADTs? [1] http://www.haskell.org/pipermail/template-haskell/2006-August/000567.html On 14 April 2010 10:32, Ozgur Akgun <ozgurakgun(a)gmail.com<mailto:ozgurakgun@gmail.com>> wrote: answering to myself: I guess this is related: http://hackage.haskell.org/trac/ghc/ticket/3497 On 14 April 2010 10:13, Ozgur Akgun <ozgurakgun(a)gmail.com<mailto:ozgurakgun@gmail.com>> wrote: Cafe, How can I provide a Data instance for a GADT? I am trying to TH on it, and Uniplate requires Data. I tried StandaloneDeriving, but it seems not to work.

1 0

6.12.3-candidate
by Serge D. Mechveliani 24 May '10

24 May '10

Dear GHC developers, I have tested ghc-6.12.3-candidate of 6.12.2.20100521 on Debian Linux, i386-family on making it by ghc-6.12.2, on making it by itself on the DoCon test, on the Dumatel test -- with skipping profiling. It looks all right. ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

Re: Dynamic libraries and GHCi
by John Lato 20 May '10

20 May '10

> From: Simon Marlow <marlowsd(a)gmail.com> >> > >> But currently there is one problem with "GhcShared=YES": with this >> option, the stage-2 compiler gets linked dynamically but the >> corresponding inplace shell wrapper does not set (DY)LD_LIBRARY_PATH, >> thus ./inplace/bin/ghc-stage2 doesn't run at all. I could work around >> this by manually symlinking all the dynamic libraries to ./inplace/lib >> and setting (DY)LD_LIBRARY_PATH to there, but obvisouly there should >> be a solution better than this. > > On Linux we link the binary using -rpath (I know OS X doesn't have > -rpath). This is another issue we need to resolve before we can switch > to a dynamically-linked GHCi. > > Basically there's a fair bit to do to make a dynamic GHCi a reality, and > before we can do anything there are some tricky decisions to make. > When you say OSX doesn't have -rpath, do you mean there's some problem with using -rpath on OSX? I have code that links to a 3rd-party library (libcudart.dylib) at runtime and it seems to use -rpath fine. This is with ghc-6.12.1. John

3 5

Re: [Haskell-cafe] cabal: problem building ffi shared library and significance of __stginit
by Duncan Coutts 19 May '10

19 May '10

On Tue, 2010-05-18 at 17:31 -0400, Anthony LODI wrote: > Hello, > > I'm trying to build some haskell code as a .so/.dll so that it can > ultimately be used by msvc. I have it working when I compile by hand > (listed below) but I can't get the exact same thing built/linked with > cabal. On linux everything builds fine, but when I try to link the > resulting .so file, I get an error about a missing > '__stginit_CInterface' reference. Indeed I couldn't find that name in > any of the cabal-generated .dyn_o files. I checked the output of > 'cabal build -v' and it seems to be executing about the same thing > that I'm executing manually so I'm not sure what could be going wrong. > On windows cabal won't even configure since '--enable-shared' seems > to imply '-dynamic' (right?), and that's not currently supported. > > Also, when I remove the line 'hs_add_root(__stginit_CInterface);', and > the corresponding forward declaration, the program runs fine! Does > ghc no longer need this call or are my toy programs just being lucky > sofar? For reference for other people, Anthony and I worked this out today. full example: http://pastebin.com/aLdyFMPg The difference between doing it manually and building a library via Cabal is the package name. When building directly with ghc, the default package name is "" aka the main package. When building a ghc/Haskell package, the package name gets set (ghc -package-name test-0.0). This package name gets encoded into the symbol names. So we get: __stginit_testzm0zi0_CInterface vs __stginit_CInterface (testzm0zi0 is the Z-encoding of test-0.0) What is bad here is that the __stginit stuff is even necessary. Anthony is going to file a ghc ticket and/or complain on the ghc users list, citing this example. Duncan

1 0

Dynamic libraries and GHCi
by Simon Marlow 18 May '10

18 May '10

We had planned to switch to using a dynamically-linked GHCi for 6.14.1 (see http://hackage.haskell.org/trac/ghc/ticket/3658) which on the whole seems like the right direction to be heading in, since we reduce the dependence on our own RTS linker. The dynamically-linked GHCi works, and passes all the tests. It also starts up faster than the statically linked one, at least on Linux, possibly due to a combination of the system linker being faster than ours and it doing on-demand linking. That's the good news. But I've realised this transition won't be as easy as I thought. Currently if you build a package dynamically (Cabal's --enable-dynamic), then you get a completely separate build of the package, with its own interface files and so on - it's a "way", in the same sense as profiling. This seemed obviously the sensible thing to do, since we really are compiling the code multiple times, and the results might be different. However, it gives us a problem with GHCi. If GHCi is dynamically linked, then it can only load object code that is compiled with -dynamic, because then the object code will be compiled against the right .hi files. I see only three possibilities: - we make -dynamic the default. - we somehow make the two ways compatible. This would probably entail compiling both versions at the same time, so we get the same Core, but running the code generator twice. I think there might be some technical problems with doing this, as we sometimes turn static data into dynamic data when compiling with -dynamic. If we could work around this, though, the general idea would still require a lot of changes in build systems, Cabal, GHC and so on. - packages should have predictable & stable ABIs. I've been wanting to do this for a long time, but we're not ready yet, and even so I hadn't planned to impose stable ABIs on every package - e.g. doing this for the base package would probably limit cross-module optimisation too much. It's perhaps worth investigating the consequences of the first option, making -dynamic the default. Cabal would have to --enable-dynamic by default - perhaps it would get an --enable-static that could even be *off* by default. We would have to measure the performance implications carefully. I know that right now the GC takes quite a severe performance hit (about 30% or so) when compiled with -fPIC on x86, due to losing the %ebx register. I think that's unacceptable, but I haven't managed to fix it yet. I don't have a clear idea for how to proceed, so I thought I'd describe the issues here and see if we can come up with a plan. Cheers, Simon

4 5