From daniil.elovkov at googlemail.com Tue Jan 1 06:24:15 2008 From: daniil.elovkov at googlemail.com (Daniil Elovkov) Date: Tue Jan 1 06:18:23 2008 Subject: laura.daun@web.am Message-ID: ?????? ?????! ? ????? ????? ???? ? ??? ???? ?????! ???? ??????? ???? ??? ???? ??????. ???? ????? ??????????. ????? ???? ????? ?????? ? ?????. ?? ???? ?????? ????????, ?????????? ???????? ???????, ???????, ???. ????? ??? ? ???? ????? ???????, ?????????, ???? ???????? ? ???? ??????! Gott nytt ?r till dig, ?ke, Aram och David (och deras flickor ocks?) ! ???? ? ????. From asviraspossible at gmail.com Tue Jan 1 13:27:32 2008 From: asviraspossible at gmail.com (Victor Nazarov) Date: Tue Jan 1 13:21:34 2008 Subject: Redefining built in syntax In-Reply-To: <404396ef0712310858l44c73920s284b5c738c5b776e@mail.gmail.com> References: <404396ef0712310858l44c73920s284b5c738c5b776e@mail.gmail.com> Message-ID: On Dec 31, 2007 7:58 PM, Neil Mitchell wrote: > Hi, > > I'm getting errors such as: > > C:/Documents/Uni/packages/base/GHC/Base.lhs:270:12: > Illegal binding of built-in syntax: [] > > When I try and compile GHC/Base.lhs using the GHC API. Is there some > flag I can pass to allow the rebinding of built in syntax? > -package-name base should do the thing -- vir http://vir.comtv.ru/ From daniil.elovkov at googlemail.com Tue Jan 1 14:16:32 2008 From: daniil.elovkov at googlemail.com (Daniil Elovkov) Date: Tue Jan 1 14:10:38 2008 Subject: Was wrong address In-Reply-To: References: Message-ID: Erm, sorry for the spam. I failed to manage my email program :) Happy New Year everybody. On Tue, 01 Jan 2008 14:24:15 +0300, Daniil Elovkov wrote: > ?????? ?????! > ... From simonmarhaskell at gmail.com Wed Jan 2 07:48:28 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed Jan 2 07:42:40 2008 Subject: ANNOUNCE: GHC version 6.8.2 In-Reply-To: References: <20071212184457.GA8806@matrix.chaos.earth.li> <5A789366-EC12-4642-A806-AD009A06BFD1@cse.unsw.edu.au> <2DAAD1F4-80A6-41FC-B8E6-BADF14D69873@cse.unsw.edu.au> <20071223140444.GA22326@matrix.chaos.earth.li> Message-ID: <477B881C.9010802@gmail.com> alpheccar wrote: > Was someone able to build ghc 6.8.2 on PPC with OS X 10.4 (Tiger) ? > I had no problems to build the 6.8.1 but with 6.8.2, I get the error: > > ../../compiler/stage1/ghc-inplace -package-name base-3.0.1.0 > -hide-all-packages -split-objs -i -idist/build/autogen -idist/build -i. > -Idist/build -Iinclude -#include "HsBase.h" -odir dist/build -hidir > dist/build -stubdir dist/build -package rts-1.0 -O -fglasgow-exts > -package-name base -XCPP -idist/build -H16m -O -O -Rghc-timing > -fgenerics -c Data/Generics/Twins.hs -o > dist/build/Data/Generics/Twins.o -ohi dist/build/Data/Generics/Twins.hi > ghc-6.8.2: panic! (the 'impossible' happened) > (GHC version 6.8.2 for powerpc-apple-darwin): > lookupVers1 base:GHC.Prim sym{tc} This is a new bug in 6.8.2 that we discovered just before Christmas: http://hackage.haskell.org/trac/ghc/ticket/2011 the workaround is simple: just make clean in libraries/base. Cheers, Simon From simonmarhaskell at gmail.com Wed Jan 2 08:17:03 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed Jan 2 08:11:05 2008 Subject: [Haskell-cafe] Re: #haskell works In-Reply-To: <13388119.20071220165420@gmail.com> References: <4762E3A2.1060701@btinternet.com> <625b74080712141257s33b1b49fp71465cbfc7039e0@mail.gmail.com> <4683d9370712142013x1749159fxc5656f51e6d53329@mail.gmail.com> <476A67C7.7040700@microsoft.com> <13388119.20071220165420@gmail.com> Message-ID: <477B8ECF.1020009@gmail.com> Bulat Ziganshin wrote: > Hello Simon, > > Thursday, December 20, 2007, 4:01:59 PM, you wrote: > >> Fixing it all properly means some fairly significant architectural changes, >> and dropping the via-C backend > > oh, thank you. from my POV, C backend still may be used together with > "non-registerized" compilers. in particular, i hope that win-x64 will > be supported at least in this way > > noone asked my question about plans of win-x64 support. it's important > for my users, so i ask you again - can you please implement it? > > to other GHC users: i'm pretty sure that win-x64 support will not be > implemented if it's required only for me. so, if someone need it - > please write about this to ghc debelopers It'll get implemented when (a) there is a working mingw64, and (b) it is important enough to enough people. As I understand it, (a) is getting closer, but there's still no official release. My guess is that it's a couple of weeks' work. Win64 is quite different from the x86-64 Unix ABI: the calling convention is different, which means that all the FFI stuff has to be ported (the NCG foreign call support, GHCi foreign calls, rts/Adjustor.c). It took me a few days to get these working for x86-64 on Unix. What's more, while x86-64 on Unix is nicer in many ways than the 32-bit ABI, Win64 is significantly more horrible than Win32 (just MHO based on memories of reading a couple of MSDN articles), so I don't expect it to be a very enjoyable couple of weeks work :) Cheers, Simon From simonmarhaskell at gmail.com Wed Jan 2 08:42:37 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed Jan 2 08:36:41 2008 Subject: --make should not touch the -o file if it doesn't change it In-Reply-To: <476E8F4F.1060009@alexjacobson.com> References: <476E8F4F.1060009@alexjacobson.com> Message-ID: <477B94CD.8020607@gmail.com> Alex Jacobson wrote: > Right now, if you recompile with --make, the exeutable gets a new > timestamp. That seems incorrect. Is this a bug? If the executable was re-linked, then it gets a new timestamp, since the file's contents have changed, but if no compilation or linking was required, then the executable and its timestamp remain unchanged. Seems ok to me, am I missing something? Cheers, Simon From simonmarhaskell at gmail.com Wed Jan 2 08:48:17 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed Jan 2 08:42:19 2008 Subject: <.> defined in GHC and System.FilePath In-Reply-To: <404396ef0712310714j48cdc759q6d16e7cd1c366cc7@mail.gmail.com> References: <404396ef0712310714j48cdc759q6d16e7cd1c366cc7@mail.gmail.com> Message-ID: <477B9621.5040706@gmail.com> Neil Mitchell wrote: > The GHC API uses the <.> operator, which clashes with System.FilePath. > Possibly this might want renaming to something else - I have > absolutely no idea what it does! > > Prelude> :m GHC > Prelude GHC> :i <.> > (<.>) :: HsWrapper -> HsWrapper -> HsWrapper -- Defined in HsBinds I tend to use import qualified GHC import GHC (Name, Id, ...) i.e. qualify most things, but selectively import a few things unqualified. The GHC API is quite huge, I expect clashes to be fairly common if you import it unqualified. Cheers, Simon From simonmarhaskell at gmail.com Wed Jan 2 09:14:34 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed Jan 2 09:08:43 2008 Subject: [Haskell] garbage collection of Concurrent Haskell threads? In-Reply-To: References: Message-ID: <477B9C4A.5040404@gmail.com> [ moving to glasgow-haskell-users@haskell.org ] Conal Elliott wrote: > Thanks, Simon. If I understand the mechanism you're describing, it > discards readers of an empty MVar when there are no other references to > the MVar *because* the MVar can never get written. And if there are > other readers but no writers, then I'm guessing GC wouldn't know that, > and none of the readers get discarded. Is that so? I'm not sure I understand precisely what you mean here. Do you mean when there are other running threads that might read the MVar in the future? In that case, yes, blocked readers would not be detected and sent an exception. > I think Baker & Hewitt's trick was analogous to discarding writers of an > already full MVar when there are readers (readMVar) but no takers > (takeMVar). (Though not quite, since readMVar is implemented via > takeMVar & putMVar.) It shouldn't be the case that you have a thread doing putMVar on a full MVar simultaneously with another thread doing readMVar, because the readMVar could be preempted between the take and put and then block - this would almost certainly be an undesirable race condition. > I guess that effectively means IVars instead of MVars. > > In either direction (blocked reader or blocked writer), the interface of > MVars (or IVars) would seem to prevent an accurate analysis, since GC > wouldn't know whether a Var reference was for reading or writing. > > Right? A simple solution might be to hide the Var itself and instead > expose reader and writer halves. If there's an analysis problem at all, > does that solution make sense? Absolutely. It ought to be possible to implement this using weak pointers in GHC, because you want relationships like "if a writer is alive, then the readers are alive", and this is the kind of thing you can express with weak pointers. Cheers, Simon > > Cheers, - Conal > > On Dec 24, 2007 1:02 AM, Simon Peyton-Jones > wrote: > > GHC already garbage-collects threads that are blocked on an MVar > that is otherwise inaccessible (and hence cannot be updated). More > precisely, GHC sends the thread an asynchronous exception > (ThreadBlocked or something), so that it has a chance to clean up. > > > > So perhaps the GC you want is already implemented? > > Simon > > > > *From:* haskell-bounces@haskell.org > > [mailto:haskell-bounces@haskell.org > ] *On Behalf Of *Conal Elliott > *Sent:* 24 December 2007 00:15 > *To:* haskell@haskell.org > *Subject:* [Haskell] garbage collection of Concurrent Haskell threads? > > > > The classic paper "The Incremental Garbage Collection of Processes" > (http://citeseer.ist.psu.edu/baker77incremental.html) describes > "futures" and how particularly garbage collecting them when their > pending result is no longer referenced. I've been playing with an > implementation of futures in Concurrent Haskell ( > http://haskell.org/haskellwiki/Reactive), using MVars, and I'm > stumped about how to GC non-winning threads in a race between > futures ("parallel or"). I'm having winner kill loser, which seems > to work fine, though is potentially dangerous w.r.t locked > resources. Still, the elegance of a GC-based solution appeals to > me. Has anyone explored process GC ideas for Concurrent Haskell (or > STM)? > > Futures are implemented using Concurrent Haskell's MVars. I first > tried using STM and TVars, simply using orElse to implement mappend > for futures. However, I didn't see how to avoid nesting > "atomically", which yielded a run-time error. If anyone has ideas > about using STM & TVars for futures, I'd love to hear. > > Thanks, - Conal > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell From alex at alexjacobson.com Wed Jan 2 10:18:52 2008 From: alex at alexjacobson.com (Alex Jacobson) Date: Wed Jan 2 10:13:34 2008 Subject: --make should not touch the -o file if it doesn't change it In-Reply-To: <477B94CD.8020607@gmail.com> References: <476E8F4F.1060009@alexjacobson.com> <477B94CD.8020607@gmail.com> Message-ID: <477BAB5C.9050908@alexjacobson.com> I think this was a bug on my part. Some file was getting touched that I wasn't aware of. Sorry. -Alex- Simon Marlow wrote: > Alex Jacobson wrote: >> Right now, if you recompile with --make, the exeutable gets a new >> timestamp. That seems incorrect. Is this a bug? > > If the executable was re-linked, then it gets a new timestamp, since the > file's contents have changed, but if no compilation or linking was > required, then the executable and its timestamp remain unchanged. Seems > ok to me, am I missing something? > > Cheers, > Simon From isaacdupree at charter.net Wed Jan 2 13:12:12 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Wed Jan 2 13:06:17 2008 Subject: odd GHC 6.8.2 compile failure Message-ID: <477BD3FC.9010302@charter.net> linking the compiled stage2 failed when bootstrapping from 6.6.1, with --prefix=$HOME . It's odd because I previously had a 6.8.2 (official x86 Linux bin-dist) installed as root (it's gone now), and I still have a bunch of cabal/hackage packages installed in $HOME that were compiled by that 6.8.2 (in addition to a few things installed by `cabal install` in ~/.cabal/). Do you think that could be confusing the build process, and if it is, is that a bug - and a bug in what? ... make[3]: Leaving directory `/Users/me/programming/cabalz/NotActuallyCabalButMaybeShouldBe/ghc-6.8.2/compiler' make -f Makefile.ghcbin -wr HS_PROG=stage2/ghc-6.8.2 stage2/ghc-6.8.2 make[3]: Entering directory `/Users/me/programming/cabalz/NotActuallyCabalButMaybeShouldBe/ghc-6.8.2/compiler' ../compiler/stage1/ghc-inplace -H16m -O -package ghc -Istage2 -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -Rghc-timing -DGHCI -threaded -fforce-recomp -c main/Main.hs -o stage2/main/Main.o -ohi stage2/main/Main.hi <> ../compiler/stage1/ghc-inplace -o stage2/ghc-6.8.2 -H16m -O -package ghc -Istage2 -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -Rghc-timing -DGHCI -threaded -fforce-recomp stage2/main/Main.o /Users/me/HOME/lib/Cabal-1.2.3.0/ghc-6.8.2/libHSCabal-1.2.3.0.a(InstalledPackageInfo.o): In function `sEZA_info': (.text+0x177c4): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_lvl21_closure' /Users/me/HOME/lib/Cabal-1.2.3.0/ghc-6.8.2/libHSCabal-1.2.3.0.a(InstalledPackageInfo.o): In function `sEZA_info': (.text+0x177cb): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_lvl22_closure' /Users/me/HOME/lib/Cabal-1.2.3.0/ghc-6.8.2/libHSCabal-1.2.3.0.a(InstalledPackageInfo.o): In function `sF0s_info': (.text+0x17974): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_lvl21_closure' /Users/me/HOME/lib/Cabal-1.2.3.0/ghc-6.8.2/libHSCabal-1.2.3.0.a(InstalledPackageInfo.o): In function `sF0s_info': (.text+0x1797b): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_lvl22_closure' /Users/me/HOME/lib/Cabal-1.2.3.0/ghc-6.8.2/libHSCabal-1.2.3.0.a(Package.o): In function `shme_info': (.text+0x100d): undefined reference to `base_DataziList_zdsintersperse_info' /Users/me/HOME/lib/Cabal-1.2.3.0/ghc-6.8.2/libHSCabal-1.2.3.0.a(ParseUtils.o): In function `swtq_info': (.text+0xa879): undefined reference to `base_DataziList_zdsintersperse_info' /Users/me/HOME/lib/Cabal-1.2.3.0/ghc-6.8.2/libHSCabal-1.2.3.0.a(ParseUtils.o): In function `swtC_info': (.text+0xa999): undefined reference to `base_DataziList_zdsintersperse_info' /Users/me/HOME/lib/Cabal-1.2.3.0/ghc-6.8.2/libHSCabal-1.2.3.0.a(Version.o): In function `r7DH_info': (.text+0x27d7): undefined reference to `base_TextziParserCombinatorsziReadP_zdschoice_info' /Users/me/HOME/lib/Cabal-1.2.3.0/ghc-6.8.2/libHSCabal-1.2.3.0.a(Version.o): In function `r7DH_srt': (.data+0x454): undefined reference to `base_TextziParserCombinatorsziReadP_zdschoice_closure' collect2: ld returned 1 exit status <> make[3]: *** [stage2/ghc-6.8.2] Error 1 make[3]: Leaving directory `/Users/me/programming/cabalz/NotActuallyCabalButMaybeShouldBe/ghc-6.8.2/compiler' make[2]: *** [stage2/ghc-6.8.2] Error 2 make[2]: Leaving directory `/Users/me/programming/cabalz/NotActuallyCabalButMaybeShouldBe/ghc-6.8.2/compiler' make[1]: *** [stage2] Error 2 make[1]: Leaving directory `/Users/me/programming/cabalz/NotActuallyCabalButMaybeShouldBe/ghc-6.8.2' make: *** [bootstrap2] Error 2 ~Isaac From simonmarhaskell at gmail.com Thu Jan 3 04:30:02 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu Jan 3 04:24:04 2008 Subject: odd GHC 6.8.2 compile failure In-Reply-To: <477BD3FC.9010302@charter.net> References: <477BD3FC.9010302@charter.net> Message-ID: <477CAB1A.9070409@gmail.com> Isaac Dupree wrote: > linking the compiled stage2 failed when bootstrapping from 6.6.1, with > --prefix=$HOME . > > It's odd because I previously had a 6.8.2 (official x86 Linux bin-dist) > installed as root (it's gone now), and I still have a bunch of > cabal/hackage packages installed in $HOME that were compiled by that > 6.8.2 (in addition to a few things installed by `cabal install` in > ~/.cabal/). Do you think that could be confusing the build process, and > if it is, is that a bug - and a bug in what? It looks like at some point you've updated your sources and recompiled without cleaning in stage2, or something similar. The build system doesn't currently notice when libraries have changed and stage2 needs to be completely recompiled. Cheers, Simon > > ... > make[3]: Leaving directory > `/Users/me/programming/cabalz/NotActuallyCabalButMaybeShouldBe/ghc-6.8.2/compiler' > > make -f Makefile.ghcbin -wr HS_PROG=stage2/ghc-6.8.2 stage2/ghc-6.8.2 > make[3]: Entering directory > `/Users/me/programming/cabalz/NotActuallyCabalButMaybeShouldBe/ghc-6.8.2/compiler' > > ../compiler/stage1/ghc-inplace -H16m -O -package ghc -Istage2 -cpp > -fglasgow-exts -fno-generics -Rghc-timing -I. -IcodeGen -InativeGen > -Iparser -Rghc-timing -DGHCI -threaded -fforce-recomp -c > main/Main.hs -o stage2/main/Main.o -ohi stage2/main/Main.hi > < residency (5 samples), 42M in use, 0.00 INIT (0.00 elapsed), 0.83 MUT > (0.91 elapsed), 0.40 GC (0.43 elapsed) :ghc>> > ../compiler/stage1/ghc-inplace -o stage2/ghc-6.8.2 -H16m -O -package ghc > -Istage2 -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -IcodeGen > -InativeGen -Iparser -Rghc-timing -DGHCI -threaded -fforce-recomp > stage2/main/Main.o > /Users/me/HOME/lib/Cabal-1.2.3.0/ghc-6.8.2/libHSCabal-1.2.3.0.a(InstalledPackageInfo.o): > In function `sEZA_info': > (.text+0x177c4): undefined reference to > `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_lvl21_closure' > /Users/me/HOME/lib/Cabal-1.2.3.0/ghc-6.8.2/libHSCabal-1.2.3.0.a(InstalledPackageInfo.o): > In function `sEZA_info': > (.text+0x177cb): undefined reference to > `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_lvl22_closure' > /Users/me/HOME/lib/Cabal-1.2.3.0/ghc-6.8.2/libHSCabal-1.2.3.0.a(InstalledPackageInfo.o): > In function `sF0s_info': > (.text+0x17974): undefined reference to > `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_lvl21_closure' > /Users/me/HOME/lib/Cabal-1.2.3.0/ghc-6.8.2/libHSCabal-1.2.3.0.a(InstalledPackageInfo.o): > In function `sF0s_info': > (.text+0x1797b): undefined reference to > `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_lvl22_closure' > /Users/me/HOME/lib/Cabal-1.2.3.0/ghc-6.8.2/libHSCabal-1.2.3.0.a(Package.o): > In function `shme_info': > (.text+0x100d): undefined reference to > `base_DataziList_zdsintersperse_info' > /Users/me/HOME/lib/Cabal-1.2.3.0/ghc-6.8.2/libHSCabal-1.2.3.0.a(ParseUtils.o): > In function `swtq_info': > (.text+0xa879): undefined reference to > `base_DataziList_zdsintersperse_info' > /Users/me/HOME/lib/Cabal-1.2.3.0/ghc-6.8.2/libHSCabal-1.2.3.0.a(ParseUtils.o): > In function `swtC_info': > (.text+0xa999): undefined reference to > `base_DataziList_zdsintersperse_info' > /Users/me/HOME/lib/Cabal-1.2.3.0/ghc-6.8.2/libHSCabal-1.2.3.0.a(Version.o): > In function `r7DH_info': > (.text+0x27d7): undefined reference to > `base_TextziParserCombinatorsziReadP_zdschoice_info' > /Users/me/HOME/lib/Cabal-1.2.3.0/ghc-6.8.2/libHSCabal-1.2.3.0.a(Version.o): > In function `r7DH_srt': > (.data+0x454): undefined reference to > `base_TextziParserCombinatorsziReadP_zdschoice_closure' > collect2: ld returned 1 exit status > < samples), 16M in use, 0.00 INIT (0.00 elapsed), 0.02 MUT (5.00 elapsed), > 0.01 GC (0.02 elapsed) :ghc>> > make[3]: *** [stage2/ghc-6.8.2] Error 1 > make[3]: Leaving directory > `/Users/me/programming/cabalz/NotActuallyCabalButMaybeShouldBe/ghc-6.8.2/compiler' > > make[2]: *** [stage2/ghc-6.8.2] Error 2 > make[2]: Leaving directory > `/Users/me/programming/cabalz/NotActuallyCabalButMaybeShouldBe/ghc-6.8.2/compiler' > > make[1]: *** [stage2] Error 2 > make[1]: Leaving directory > `/Users/me/programming/cabalz/NotActuallyCabalButMaybeShouldBe/ghc-6.8.2' > make: *** [bootstrap2] Error 2 > > > ~Isaac > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From isaacdupree at charter.net Thu Jan 3 06:34:37 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Thu Jan 3 06:28:34 2008 Subject: odd GHC 6.8.2 compile failure In-Reply-To: <477CAB1A.9070409@gmail.com> References: <477BD3FC.9010302@charter.net> <477CAB1A.9070409@gmail.com> Message-ID: <477CC84D.2040704@charter.net> Simon Marlow wrote: > Isaac Dupree wrote: >> linking the compiled stage2 failed when bootstrapping from 6.6.1, with >> --prefix=$HOME . >> >> It's odd because I previously had a 6.8.2 (official x86 Linux >> bin-dist) installed as root (it's gone now), and I still have a bunch >> of cabal/hackage packages installed in $HOME that were compiled by >> that 6.8.2 (in addition to a few things installed by `cabal install` >> in ~/.cabal/). Do you think that could be confusing the build >> process, and if it is, is that a bug - and a bug in what? > > It looks like at some point you've updated your sources and recompiled > without cleaning in stage2, or something similar. The build system > doesn't currently notice when libraries have changed and stage2 needs to > be completely recompiled. It sure looks that way! But I didn't do that personally; I think these are all of my steps: [download via Firefox to /Users/me/downloads/ghc-6.8.2-src.tar.bz2] cd /Users/me/programming/cabalz/NotActuallyCabalButMaybeShouldBe aunpack /Users/me/downloads/ghc-6.8.2-src.tar.bz2 # this `aunpack` is equivalent to tar -xjf in this case. cd ghc-6.8.2 ./configure --prefix=$HOME # ($HOME is /Users/me/HOME , by the way). make Indeed I just reproduced it, newly unpacking that tarball in a new location, to make sure, and I got the same error. What if GHC suddenly decided to link with the newer versions of the boot-libraries than come with 6.8.2, the ones that could be found in $HOME since I installed them there? (or with the _same_ versions that happened to be compiled with different flags, perhaps?) ~Isaac From simonmarhaskell at gmail.com Thu Jan 3 06:47:56 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu Jan 3 06:42:00 2008 Subject: Readline for Windows in the FAQ In-Reply-To: <6329b9500712121227k2e4e0771j7dfe7a0494f182fc@mail.gmail.com> References: <6329b9500712121227k2e4e0771j7dfe7a0494f182fc@mail.gmail.com> Message-ID: <477CCB6C.9010000@gmail.com> Walt Rorie-Baety wrote: > Maybe I'm just too new at this, but the GCH FAQ entry for readline in > GHCi is confusing for me. Especially since it ends with the sentence > "Instructions for GHC 6.2.2. are here." However, as the quote goes, > "there's no 'here' here." - the location of the instructions are missing. > > Could someone please clue me in to what I'm missing? That way, I could > edit the Wiki page, to clue in others better. I've removed the question now. I think at one time it was possible to compile readline on Windows and to compile GHCi using that readline, but I haven't done it for a long time, and I don't know if it is still possible. If you or anyone else figures out more, please add it to the wiki. Cheers, Simon From simonmarhaskell at gmail.com Thu Jan 3 06:58:16 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu Jan 3 06:52:22 2008 Subject: odd GHC 6.8.2 compile failure In-Reply-To: <477CC84D.2040704@charter.net> References: <477BD3FC.9010302@charter.net> <477CAB1A.9070409@gmail.com> <477CC84D.2040704@charter.net> Message-ID: <477CCDD8.1080905@gmail.com> Isaac Dupree wrote: > Simon Marlow wrote: >> Isaac Dupree wrote: >>> linking the compiled stage2 failed when bootstrapping from 6.6.1, >>> with --prefix=$HOME . >>> >>> It's odd because I previously had a 6.8.2 (official x86 Linux >>> bin-dist) installed as root (it's gone now), and I still have a bunch >>> of cabal/hackage packages installed in $HOME that were compiled by >>> that 6.8.2 (in addition to a few things installed by `cabal install` >>> in ~/.cabal/). Do you think that could be confusing the build >>> process, and if it is, is that a bug - and a bug in what? >> >> It looks like at some point you've updated your sources and recompiled >> without cleaning in stage2, or something similar. The build system >> doesn't currently notice when libraries have changed and stage2 needs >> to be completely recompiled. > > It sure looks that way! But I didn't do that personally; I think these > are all of my steps: > [download via Firefox to /Users/me/downloads/ghc-6.8.2-src.tar.bz2] > cd /Users/me/programming/cabalz/NotActuallyCabalButMaybeShouldBe > aunpack /Users/me/downloads/ghc-6.8.2-src.tar.bz2 > # this `aunpack` is equivalent to tar -xjf in this case. > cd ghc-6.8.2 > ./configure --prefix=$HOME > # ($HOME is /Users/me/HOME , by the way). > make > > Indeed I just reproduced it, newly unpacking that tarball in a new > location, to make sure, and I got the same error. > > > What if GHC suddenly decided to link with the newer versions of the > boot-libraries than come with 6.8.2, the ones that could be found in > $HOME since I installed them there? (or with the _same_ versions that > happened to be compiled with different flags, perhaps?) And you get different results if you omit the --prefix=$HOME? (if so, that's very strange, and I don't have a clue what's wrong, yet) Cheers, Simon From simonpj at microsoft.com Thu Jan 3 10:44:05 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Jan 3 10:38:01 2008 Subject: <.> defined in GHC and System.FilePath In-Reply-To: <404396ef0712310714j48cdc759q6d16e7cd1c366cc7@mail.gmail.com> References: <404396ef0712310714j48cdc759q6d16e7cd1c366cc7@mail.gmail.com> Message-ID: I've no objection to renaming it, if that's more convenient. It's a kind of composition operator, hence the name. Perhaps <:>? By all means send, or commit, a patch Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of | Neil Mitchell | Sent: 31 December 2007 15:15 | To: GHC Users | Subject: <.> defined in GHC and System.FilePath | | Hi | | The GHC API uses the <.> operator, which clashes with System.FilePath. | Possibly this might want renaming to something else - I have | absolutely no idea what it does! | | Prelude> :m GHC | Prelude GHC> :i <.> | (<.>) :: HsWrapper -> HsWrapper -> HsWrapper -- Defined in HsBinds | | Thanks | | Neil | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From Christian.Maeder at dfki.de Thu Jan 3 10:47:38 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Thu Jan 3 10:41:34 2008 Subject: [Fwd: Re: Problem building hdbc-sqlite3 with ghc 6.8.2] Message-ID: <477D039A.2070102@dfki.de> Hi, can someone explain the linking error below? (on Intel-Mac (Tiger?)) Preprocessing library HDBC-sqlite3-1.1.3.0... Building HDBC-sqlite3-1.1.3.0... [1 of 7] Compiling Database.HDBC.Sqlite3.Consts ( dist/build/Database/ HDBC/Sqlite3/Consts.hs, dist/build/Database/HDBC/Sqlite3/Consts.o ) [2 of 7] Compiling Database.HDBC.Sqlite3.Types ( Database/HDBC/Sqlite3/ Types.hs, dist/build/Database/HDBC/Sqlite3/Types.o ) [3 of 7] Compiling Database.HDBC.Sqlite3.Utils ( dist/build/Database/ HDBC/Sqlite3/Utils.hs, dist/build/Database/HDBC/Sqlite3/Utils.o ) [4 of 7] Compiling Database.HDBC.Sqlite3.Statement ( dist/build/ Database/HDBC/Sqlite3/Statement.hs, dist/build/Database/HDBC/Sqlite3/ Statement.o ) [5 of 7] Compiling Database.HDBC.Sqlite3.ConnectionImpl ( Database/ HDBC/Sqlite3/ConnectionImpl.hs, dist/build/Database/HDBC/Sqlite3/ ConnectionImpl.o ) [6 of 7] Compiling Database.HDBC.Sqlite3.Connection ( Database/HDBC/ Sqlite3/Connection.hs, dist/build/Database/HDBC/Sqlite3/Connection.o ) [7 of 7] Compiling Database.HDBC.Sqlite3 ( Database/HDBC/Sqlite3.hs, dist/build/Database/HDBC/Sqlite3.o ) ar: creating archive dist/build/libHSHDBC-sqlite3-1.1.3.0.a ld: atom sorting error for _HDBCzmsqlite3zm1zi1zi3zi0_DatabaseziHDBCziSqlite3ziTypes_CSqlite3_closure_tbl and _HDBCzmsqlite3zm1zi1zi3zi0_DatabaseziHDBCziSqlite3ziTypes_CStmt_closure_tbl in dist/build/Database/HDBC/Sqlite3/Types.o ld: atom sorting error for _HDBCzmsqlite3zm1zi1zi3zi0_DatabaseziHDBCziSqlite3ziTypes_CSqlite3_closure_tbl and _HDBCzmsqlite3zm1zi1zi3zi0_DatabaseziHDBCziSqlite3ziTypes_CStmt_closure_tbl in dist/build/Database/HDBC/Sqlite3/Types.o From ahey at iee.org Thu Jan 3 12:35:26 2008 From: ahey at iee.org (Adrian Hey) Date: Thu Jan 3 12:29:23 2008 Subject: Is GHC.Base deliberately hidden? Message-ID: <477D1CDE.6010605@iee.org> Hello, Why is it that the haddock docs supplied with GHC omit this module and its exports? Is it because we're not supposed to use them? I'm thinking of the compareInt# function in particular, which I use quite a lot. Thanks -- Adrian Hey From wolfgang.thaller at gmx.net Thu Jan 3 13:04:59 2008 From: wolfgang.thaller at gmx.net (Wolfgang Thaller) Date: Thu Jan 3 12:59:20 2008 Subject: [Fwd: Re: Problem building hdbc-sqlite3 with ghc 6.8.2] In-Reply-To: <477D039A.2070102@dfki.de> References: <477D039A.2070102@dfki.de> Message-ID: <73E4D7C3-4D69-4D26-9129-536C93563E29@gmx.net> On 3-Jan-08, at 4:47 PM, Christian Maeder wrote: > Hi, > > can someone explain the linking error below? (on Intel-Mac (Tiger?)) > > Preprocessing library HDBC-sqlite3-1.1.3.0... > Building HDBC-sqlite3-1.1.3.0... > [1 of 7] Compiling Database.HDBC.Sqlite3.Consts ( dist/build/Database/ > HDBC/Sqlite3/Consts.hs, dist/build/Database/HDBC/Sqlite3/Consts.o ) [...] > ar: creating archive dist/build/libHSHDBC-sqlite3-1.1.3.0.a > ld: atom sorting error for > _HDBCzmsqlite3zm1zi1zi3zi0_DatabaseziHDBCziSqlite3ziTypes_CSqlite3_closure_tbl [...] To the best of my knowledge, this is harmless and can be ignored. Linking continues after this message is printed, and I haven't yet found any adverse side-effects. The message is triggered (in Apple's recently-rewritten linker) when there are two or more labels pointing to the very end of a section in an object file. This sometimes happens when empty _closure_tbls are emitted by GHC; it's probably not too hard to prevent this from happening. Cheers, Wolfgang From ndmitchell at gmail.com Thu Jan 3 13:23:48 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu Jan 3 13:17:43 2008 Subject: <.> defined in GHC and System.FilePath In-Reply-To: References: <404396ef0712310714j48cdc759q6d16e7cd1c366cc7@mail.gmail.com> Message-ID: <404396ef0801031023x54e6ce7crbd5197c01031b71@mail.gmail.com> Hi > Simon Marlow wrote: > i.e. qualify most things, but selectively import a few things unqualified. > The GHC API is quite huge, I expect clashes to be fairly common if you > import it unqualified. > On 1/3/08, Simon Peyton-Jones wrote: > I've no objection to renaming it, if that's more convenient. It's a kind of > composition operator, hence the name. Perhaps <:>? By all means send, or > commit, a patch If the API is intended to be huge and imported qualified, it doesn't matter if there are clashes. It is trivial to use hiding to solve this, so leaving it alone is fine. Thanks Neil From ndmitchell at gmail.com Thu Jan 3 13:29:25 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu Jan 3 13:23:20 2008 Subject: Redefining built in syntax In-Reply-To: References: <404396ef0712310858l44c73920s284b5c738c5b776e@mail.gmail.com> Message-ID: <404396ef0801031029u2434294u79867a1a10c587c@mail.gmail.com> Hi Victor, > -package-name base > > should do the thing Thanks very much, that is the correct flag to allow built in syntax. However, turning that flag on also does other stuff, which breaks new things. Taking the module Prelude.hs, from a darcs checkout of the libraries: C:\Documents\Uni\packages\base>ghci Prelude.hs -i -cpp -fglasgow-exts GHCi, version 6.8.1: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Ok, modules loaded: Prelude. i.e. you can load the Prelude. However, specifying -package-name base: C:\Documents\Uni\packages\base>ghci Prelude.hs -i -cpp -fglasgow-exts -package-name base GHCi, version 6.8.1: http://www.haskell.org/ghc/ :? for help :1:22: Failed to load interface for `System.IO': it is not a module in the current program, or in any known package. :1:22: Not in scope: `System.IO.stderr' :1:22: Not in scope: `System.IO.stdin' : panic! (the 'impossible' happened) (GHC version 6.8.1 for i386-unknown-mingw32): interactiveUI:setBuffering Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This is the same behaviour as loading Prelude without specifying -i. Moving -i to other places still gives the same behaviour. Does package-name base also imply other flags (perhaps -i. ?) which are negatively effecting my particular use. For context, my particular use is to call compileToCore on each file. If the file can be loaded in GHCi, it seems that I can do the compileToCore magic. Thanks Neil From catamorphism at gmail.com Thu Jan 3 14:05:34 2008 From: catamorphism at gmail.com (Tim Chevalier) Date: Thu Jan 3 13:59:31 2008 Subject: Redefining built in syntax In-Reply-To: <404396ef0801031029u2434294u79867a1a10c587c@mail.gmail.com> References: <404396ef0712310858l44c73920s284b5c738c5b776e@mail.gmail.com> <404396ef0801031029u2434294u79867a1a10c587c@mail.gmail.com> Message-ID: <4683d9370801031105u3a2aa317p17afa4c8401a22c1@mail.gmail.com> Hi, Neil-- On 1/3/08, Neil Mitchell wrote: > Hi Victor, > > > -package-name base > > > > should do the thing > > Thanks very much, that is the correct flag to allow built in syntax. > However, turning that flag on also does other stuff, which breaks new > things. Taking the module Prelude.hs, from a darcs checkout of the > libraries: > > C:\Documents\Uni\packages\base>ghci Prelude.hs -i -cpp -fglasgow-exts > GHCi, version 6.8.1: http://www.haskell.org/ghc/ :? for help > Loading package base ... linking ... done. > Ok, modules loaded: Prelude. > > i.e. you can load the Prelude. However, specifying -package-name base: > > C:\Documents\Uni\packages\base>ghci Prelude.hs -i -cpp -fglasgow-exts > -package-name base > GHCi, version 6.8.1: http://www.haskell.org/ghc/ :? for help > > :1:22: > Failed to load interface for `System.IO': > it is not a module in the current program, or in any known package. > > :1:22: Not in scope: `System.IO.stderr' > > :1:22: Not in scope: `System.IO.stdin' > : panic! (the 'impossible' happened) > (GHC version 6.8.1 for i386-unknown-mingw32): > interactiveUI:setBuffering > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > Yeah, I've seen this before. One thing is that I generally avoid running code that uses the GHC API in GHCi, because I saw some reference somewhere to the fact that data structures can get mixed up that way, and it just seems to lead to madness :-) I've definitely seen the setBuffering panic message before, though haven't filed a bug report since I can't reproduce it reliably. In GHC, though, I can compile base package modules to Core just fine, if I provide the right import flags (-i and -I) so it can find all the dependencies. (If you want to see the complete list of flags I'm using, let me know :-) > This is the same behaviour as loading Prelude without specifying -i. > Moving -i to other places still gives the same behaviour. Does > package-name base also imply other flags (perhaps -i. ?) which are > negatively effecting my particular use. > I don't know, but in GHC (as opposed to GHCi), it all works. I can post some sample code if that would help; let me know. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "More than at any other time in history, mankind faces a crossroads. One path leads to despair and utter hopelessness. The other, to total extinction. Let us pray we have the wisdom to choose correctly."--Woody Allen From isaacdupree at charter.net Thu Jan 3 14:36:25 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Thu Jan 3 14:30:27 2008 Subject: odd GHC 6.8.2 compile failure In-Reply-To: <477CCDD8.1080905@gmail.com> References: <477BD3FC.9010302@charter.net> <477CAB1A.9070409@gmail.com> <477CC84D.2040704@charter.net> <477CCDD8.1080905@gmail.com> Message-ID: <477D3939.7070405@charter.net> Simon Marlow wrote: > Isaac Dupree wrote: >> Simon Marlow wrote: >>> Isaac Dupree wrote: >>>> linking the compiled stage2 failed when bootstrapping from 6.6.1, >>>> with --prefix=$HOME . >>>> >>>> It's odd because I previously had a 6.8.2 (official x86 Linux >>>> bin-dist) installed as root (it's gone now), and I still have a >>>> bunch of cabal/hackage packages installed in $HOME that were >>>> compiled by that 6.8.2 (in addition to a few things installed by >>>> `cabal install` in ~/.cabal/). Do you think that could be confusing >>>> the build process, and if it is, is that a bug - and a bug in what? >>> >>> It looks like at some point you've updated your sources and >>> recompiled without cleaning in stage2, or something similar. The >>> build system doesn't currently notice when libraries have changed and >>> stage2 needs to be completely recompiled. >> >> It sure looks that way! But I didn't do that personally; I think >> these are all of my steps: >> [download via Firefox to /Users/me/downloads/ghc-6.8.2-src.tar.bz2] >> cd /Users/me/programming/cabalz/NotActuallyCabalButMaybeShouldBe >> aunpack /Users/me/downloads/ghc-6.8.2-src.tar.bz2 >> # this `aunpack` is equivalent to tar -xjf in this case. >> cd ghc-6.8.2 >> ./configure --prefix=$HOME >> # ($HOME is /Users/me/HOME , by the way). >> make >> >> Indeed I just reproduced it, newly unpacking that tarball in a new >> location, to make sure, and I got the same error. >> >> >> What if GHC suddenly decided to link with the newer versions of the >> boot-libraries than come with 6.8.2, the ones that could be found in >> $HOME since I installed them there? (or with the _same_ versions that >> happened to be compiled with different flags, perhaps?) > > And you get different results if you omit the --prefix=$HOME? (if so, > that's very strange, and I don't have a clue what's wrong, yet) tested a couple more times: - it still fails without --prefix=$HOME - but it succeeds if I `su - east` and have 'east' compile it (without using --prefix here either) ('east' being another user on my machine other than the user 'me' which I usually use) Isaac From twanvl at gmail.com Thu Jan 3 21:22:52 2008 From: twanvl at gmail.com (Twan van Laarhoven) Date: Thu Jan 3 21:16:44 2008 Subject: GHC source code improvement ideas Message-ID: <477D987C.2090806@gmail.com> Hello GHC people, I was trying my hand at some GHC hacking, and I couldn't help but notice that much of the code looks (IMHO) horrible. There are some things that look as if they haven't been touched since the Haskell 1.3 days. The most striking is the use of `thenXX` instead of do notation. I was thinking of cleaning up some of this. In particular: 1a. Use do notation where possible instead of `thenXX`. 1b. Even better, use Applicative where possible. For example ds_type (HsFunTy ty1 ty2) = dsHsType ty1 `thenM` \ tau_ty1 -> dsHsType ty2 `thenM` \ tau_ty2 -> returnM (mkFunTy tau_ty1 tau_ty2) Could be rewritten as ds_type (HsFunTy ty1 ty2) = mkFunTy <$> dsHsType ty1 <*> dsHsType ty2 2. Investigate the need for all these mappM functions. To quote the source: "Standard combinators, but specialised for this monad (for efficiency)". Wouldn't a SPECIALIZE pragma work just as well? 3. In general, use standard functions when they are available. Currently GHC has its own sort function and its own versions of FiniteMap/Data.Map and Text.PrettyPrint. Using standard functions/data structures will a) make GHC smaller and therefore easier to maintain, and b) will make the code easier to understand for someone who knows the standard library. 4. A more radical change would be introducing hierarchical modules. This could be just a matter of renaming the directories to start with an upper case character and changing the import declarations. This gives module names like "Typecheck.TcGadt". The tc is redundant here, so perhaps it should be renamed to "Typecheck.Gadt" or "Typecheck.GADT". Perhaps even better would be "GHC.Typecheck.GADT", this way some modules can be exposed as part of the GHC api. How do the GHC developers feel about this? Would such paches be gladly excepted? Or will they be directly forwarded to the bit bucket? Twan From simonpj at microsoft.com Fri Jan 4 03:34:22 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Jan 4 03:28:18 2008 Subject: GHC source code improvement ideas In-Reply-To: <477D987C.2090806@gmail.com> References: <477D987C.2090806@gmail.com> Message-ID: Twan, In general I'd be delighted for you to clean up GHC's code -- thank you! There is a slight down-side which is that because you end up touching a lot of code, you get a big patch that means you can't selectively pick patches from before and after the change -- but I'm not too bothered about that, and its balanced by the clean-up. Let's also see what Simon and Ian (or others) have to say. Best to do one change per patch. A very useful thing to do would be to improve the Commentary: http://hackage.haskell.org/trac/ghc/wiki/Commentary In fiddling with GHC's codebase you will surely learn stuff that you wish you'd known to start with, and that is the Ideal Moment to capture it in writing on the Wiki. A real service to others. | 1a. Use do notation where possible instead of `thenXX`. Yes. | 1b. Even better, use Applicative where possible. For example | | ds_type (HsFunTy ty1 ty2) | = dsHsType ty1 `thenM` \ tau_ty1 -> | dsHsType ty2 `thenM` \ tau_ty2 -> | returnM (mkFunTy tau_ty1 tau_ty2) | | Could be rewritten as | | ds_type (HsFunTy ty1 ty2) | = mkFunTy <$> dsHsType ty1 <*> dsHsType ty2 This works great when you have the pattern above -- but often it's a bit more complicated and then it does not work so well. So it's hard to employ the pattern consistently. Then you have to ask whether a mixture of styles is good. My gut feel is that it's better to use do-notation consistently. | 2. Investigate the need for all these mappM functions. To quote the | source: "Standard combinators, but specialised for this monad (for | efficiency)". Wouldn't a SPECIALIZE pragma work just as well? The trouble is that currently you can only specialise a function at its definition site -- and at the definition of mapM the relevant monad isn't in scope because mapM is in a library. I have no clue whether this has any effect on performance. You could try a small experiment, by defining mappM=mapM and seeing if there was any change. | 3. In general, use standard functions when they are available. Currently | GHC has its own sort function and its own versions of FiniteMap/Data.Map and | Text.PrettyPrint. Using standard functions/data structures will a) make GHC | smaller and therefore easier to maintain, and b) will make the code easier | to understand for someone who knows the standard library. In general yes. But GHC is meant to be compilable with any GHC back to 6.2. So if the interface to a library changes between (say) 6.2 and 6.4, you end up with ifdefs. That can be a royal pain. Having the library code in the compiler source eliminates that problem. The other thing is that it's possible that GHC's version of the library has more functions. Or uses some non-standard feature like unboxed types. So proceed with caution here. Prettyprinting would be a strong candidate. FiniteMap too. But be careful with UniqFM -- it's a very very heavily-used library. | 4. A more radical change would be introducing hierarchical modules. This | could be just a matter of renaming the directories to start with an upper | case character and changing the import declarations. This gives module names | like "Typecheck.TcGadt". The tc is redundant here, so perhaps it should be | renamed to "Typecheck.Gadt" or "Typecheck.GADT". Perhaps even better would | be "GHC.Typecheck.GADT", this way some modules can be exposed as part of the | GHC api. I don't think I'd object, but I'm not sure that much is gained here. We don't spend much time on mondule-name clashes. Simon From Christian.Maeder at dfki.de Fri Jan 4 05:21:44 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Jan 4 05:15:39 2008 Subject: [Fwd: Re: Problem building hdbc-sqlite3 with ghc 6.8.2] In-Reply-To: <73E4D7C3-4D69-4D26-9129-536C93563E29@gmx.net> References: <477D039A.2070102@dfki.de> <73E4D7C3-4D69-4D26-9129-536C93563E29@gmx.net> Message-ID: <477E08B8.4060203@dfki.de> Did a final "runhaskell Setup.lhs install" work for you, Emmanuel? Thanks, Wolfgang Cheers Christian Wolfgang Thaller wrote: > On 3-Jan-08, at 4:47 PM, Christian Maeder wrote: > >> Hi, >> >> can someone explain the linking error below? (on Intel-Mac (Tiger?)) >> >> Preprocessing library HDBC-sqlite3-1.1.3.0... >> Building HDBC-sqlite3-1.1.3.0... >> [1 of 7] Compiling Database.HDBC.Sqlite3.Consts ( dist/build/Database/ >> HDBC/Sqlite3/Consts.hs, dist/build/Database/HDBC/Sqlite3/Consts.o ) > [...] >> ar: creating archive dist/build/libHSHDBC-sqlite3-1.1.3.0.a >> ld: atom sorting error for >> _HDBCzmsqlite3zm1zi1zi3zi0_DatabaseziHDBCziSqlite3ziTypes_CSqlite3_closure_tbl >> > [...] > > To the best of my knowledge, this is harmless and can be ignored. > Linking continues after this message is printed, and I haven't yet found > any adverse side-effects. > > The message is triggered (in Apple's recently-rewritten linker) when > there are two or more labels pointing to the very end of a section in an > object file. This sometimes happens when empty _closure_tbls are emitted > by GHC; it's probably not too hard to prevent this from happening. > > Cheers, > > Wolfgang > From Christian.Maeder at dfki.de Fri Jan 4 05:40:11 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Jan 4 05:34:05 2008 Subject: Unrecognized -F flag In-Reply-To: <3978AF5D-3C97-4979-882D-FCD5ACD0D6B0@gmail.com> References: <3978AF5D-3C97-4979-882D-FCD5ACD0D6B0@gmail.com> Message-ID: <477E0D0B.6020802@dfki.de> Thanks, for your report. It was my fault. I should not have modified utils/hsc2hs/Main.hs as described in the following links. http://article.gmane.org/gmane.comp.lang.haskell.glasgow.user/13583 http://hackage.haskell.org/trac/ghc/ticket/1395 A fix is to replace your file /lib/ghc-6.8.2/hsc2hs-bin with a new one that you can download from: http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/intel-mac/versions/hsc2hs-bin (635468 Bytes) a ppc version from: http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/mac/versions/hsc2hs-bin (800044 Bytes) above is /usr/local (or the one you've configured with) Does someone have a cute command to easily update this file in a binary distribution (without unpacking and repacking), so that Ian can replaced my binary-dists (replacing hsc2hs-bin manually is a bit of a pain). Christian Adam Smyczek wrote: > Hi Christian, > > I'm using your OS X (Tiger) Intel ghc-6.8.2 distribution downloaded from > haskell.org. > So far everything worked great until I run into one problem compiling > zlib 0.4.0.1. > Running build command I get the following error: > > Preprocessing library zlib-0.4.0.1... > ghc-6.8.2: unrecognised flags: -F/Users/asmyczek/Library/Frameworks > Usage: For basic information, try the `--help' option. > compiling dist/build/Codec/Compression/Zlib/Stream_hsc_make.c failed > command was: /opt/local/bin/ghc -c -package base-3.0.1.0 -package > bytestring-0.9.0.1 -F/Users/asmyczek/Library/Frameworks > dist/build/Codec/Compression/Zlib/Stream_hsc_make.c -o > dist/build/Codec/Compression/Zlib/Stream_hsc_make.o > > I'm newbie to Haskell, Cabal etc. and not sure what the root cause of > this problem is. > Google did not find any concrete solution as well. Do you have an idea > what the problem > could be or maybe some hints where I can start to dig into? > > Thanks, > Adam > > From Christian.Maeder at dfki.de Fri Jan 4 06:03:10 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Jan 4 05:57:04 2008 Subject: http://www.haskell.org/ghc/dist/mac_frameworks/GNUreadline-framework.zip In-Reply-To: <200801032058.47615.naur@post11.tele.dk> References: <477CE624.3040806@dfki.de> <20080103151849.DJSH5833.fep27.mail.dk@matrix.matrix.chaos.earth.li> <200801032058.47615.naur@post11.tele.dk> Message-ID: <477E126E.90301@dfki.de> (Let's discuss this openly on glasgow-haskell-users) I'm not happy about this framework hick-hack either. I've only pushed it, because we needed a readline solution on macs. The alternative is to use static linking of gmp (as suggested by chak) _and_ readline (version 5), so that user programs are also statically linked with these libs. Nobody supplied a binary distribution so far, though. I only supplied the binary distributions that I (naively) made anyway. Regarding this actual GNUreadline-framework.zip replacement, this is harmless and seems to matter only for those who build ghc with frameworks (as only the inclusion of header files changed) In any case we should strive to fix the frameworks issues _and_ add support for static linking of gmp, readline and possibly other libs (plus license issues). HTH Christian Thorkil Naur wrote: > Hello, > > Thanks everybody. However, I believe that using a modified readline library is > debatable, mainly because it adds the burden of keeping this library > up-to-date to the GHC maintenance process. Having a renamed library is one > thing and it does not seem that also modifying the contents of the library is > an improvement. For me to consider this idea, it should be the very last > solution, every other stone having been turned. And I certainly believe that > stones remain to be turned in this case. > > I would very much like to hear your comments to this. > > In addition, if you must replace this framework with another with different > contents, I would suggest the use of some versioning scheme. Otherwise is > seems that a lot of confusion could result. > > Thanks and best regards > Thorkil > > On Thursday 03 January 2008 16:18, Ian Lynagh wrote: >> Hi Christian, >> >> On Thu, Jan 03, 2008 at 02:41:56PM +0100, Christian Maeder wrote: >>> Judah's framework (2342543 Bytes) >>> http://www.math.ucla.edu/~jjacobson/ghc/GNUreadline-framework.zip >>> >>> should replace (my old one) >>> http://www.haskell.org/ghc/dist/mac_frameworks/GNUreadline-framework.zip >> Done! >> >> >> Thanks >> Ian >> >> From simonpj at microsoft.com Fri Jan 4 06:23:48 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Jan 4 06:17:42 2008 Subject: Redefining built in syntax In-Reply-To: <404396ef0801031029u2434294u79867a1a10c587c@mail.gmail.com> References: <404396ef0712310858l44c73920s284b5c738c5b776e@mail.gmail.com> <404396ef0801031029u2434294u79867a1a10c587c@mail.gmail.com> Message-ID: | C:\Documents\Uni\packages\base>ghci Prelude.hs -i -cpp -fglasgow-exts | -package-name base | GHCi, version 6.8.1: http://www.haskell.org/ghc/ :? for help | | :1:22: | Failed to load interface for `System.IO': | it is not a module in the current program, or in any known package. I don't think we'd ever thought of doing this. In particular, I don't think we'd every considered using GHCi in combination with -package-name. Furthermore, I'm not sure we've ever thought what should happen if you use -package-name foo, when compiling with a compiler that already has a package 'foo' (with an identical name) installed. Probably we should check for this case, because it looks likely to lead to confusion. The immediate problem is that GHCi looks for the value "System.IO.stdout" so that it can use it to print things, and it can't find module System.IO, I think because you've overridden the base-package binding. Do you have to use GHCi for this stuff? It's delicate, because GHCi prints things, but you want to compile the very functions it is using to do the printing... Simon From isaacdupree at charter.net Fri Jan 4 07:17:23 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Fri Jan 4 07:11:25 2008 Subject: GHC source code improvement ideas In-Reply-To: References: <477D987C.2090806@gmail.com> Message-ID: <477E23D3.1000109@charter.net> Simon Peyton-Jones wrote: > | 4. A more radical change would be introducing hierarchical modules. This > | could be just a matter of renaming the directories to start with an upper > | case character and changing the import declarations. This gives module names > | like "Typecheck.TcGadt". The tc is redundant here, so perhaps it should be > | renamed to "Typecheck.Gadt" or "Typecheck.GADT". Perhaps even better would > | be "GHC.Typecheck.GADT", this way some modules can be exposed as part of the > | GHC api. > > I don't think I'd object, but I'm not sure that much is gained here. We don't > spend much time on mondule-name clashes. I vote for this, as it makes it easier to progress to standard module-chasing such as Cabal or `ghc --make`, and everyone supports hierarchical modules nowadays. (I might do it myself, if appropriate) warning: calling them "GHC.*" clashes with base's use of that namespace for implementation-specific functions in compiled programs, INCLUDING ghc (I mean, GHC code sometimes says "import GHC.Exts") ... so let's please find a different name-prefix if we decide we want one. ~Isaac From simonmarhaskell at gmail.com Fri Jan 4 07:27:48 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Fri Jan 4 07:21:44 2008 Subject: Is GHC.Base deliberately hidden? In-Reply-To: <477D1CDE.6010605@iee.org> References: <477D1CDE.6010605@iee.org> Message-ID: <477E2644.4060707@gmail.com> Adrian Hey wrote: > Why is it that the haddock docs supplied with GHC omit this module and > its exports? Is it because we're not supposed to use them? I'm thinking > of the compareInt# function in particular, which I use quite a lot. We don't intend GHC.Base to be a stable interface for external use, which is why we don't document it. Use at your own risk! If there's useful stuff in GHC.Base, then arguably we should have a published stable interface from which to get it, though. Cheers, Simon From simonpj at microsoft.com Fri Jan 4 08:15:13 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Jan 4 08:09:06 2008 Subject: Rank-2 polymorphism and pattern matching In-Reply-To: References: Message-ID: | > The following won't compile for me | > | > isnull :: (forall a . [a]) -> Bool | > isnull ([] :: forall b . [b]) = True | > | > Couldn't match expected type `forall b. [b]' | > against inferred type `[a]' | > In the pattern: [] This is a pretty strange thing to do, to match a polymorphic argument against a data constructor. I guess you'd expect this to work too, perhaps? f :: forall a. (forall b. Either a b) -> a f (Left x) = x I grant that arguably these should work, but I think it'd be quite tricky to make it do so, because it'd involve re-generalising in the pattern. Furthermore, I can't see any use for it. Just remove the type signature from the pattern. One could argue that it's a bad sign that the pattern typechecker should have difficulty with this. But until it turns out to be important I'm not going to lose sleep over it! Interesting example though. Perhaps the error message should be better. Simon From simonmarhaskell at gmail.com Fri Jan 4 08:42:16 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Fri Jan 4 08:36:13 2008 Subject: Redefining built in syntax In-Reply-To: References: <404396ef0712310858l44c73920s284b5c738c5b776e@mail.gmail.com> <404396ef0801031029u2434294u79867a1a10c587c@mail.gmail.com> Message-ID: <477E37B8.40701@gmail.com> Simon Peyton-Jones wrote: > | C:\Documents\Uni\packages\base>ghci Prelude.hs -i -cpp -fglasgow-exts > | -package-name base > | GHCi, version 6.8.1: http://www.haskell.org/ghc/ :? for help > | > | :1:22: > | Failed to load interface for `System.IO': > | it is not a module in the current program, or in any known package. > > I don't think we'd ever thought of doing this. In particular, I don't think we'd every considered using GHCi in combination with -package-name. I can't off the top of my head think of a reason why it should fail, unless you use a special -package-name like base, rts, haskell98 or template-haskell. > Furthermore, I'm not sure we've ever thought what should happen if you use -package-name foo, when compiling with a compiler that already has a package 'foo' (with an identical name) installed. Probably we should check for this case, because it looks likely to lead to confusion. This certainly works, because it must be possible to recompile a package P even though P is installed - it happens when you go back in libraries/ and say 'make', for example. Normally the already-installed P is hidden, because Cabal passes -hide-all-packages to GHC, so things work out fine. Probably GHC ought to filter out P and anything that depends on it from the set of installed packages anyway, to prevent strange things from happening. Cheers, Simon From simonmarhaskell at gmail.com Fri Jan 4 09:06:33 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Fri Jan 4 09:00:31 2008 Subject: GHC source code improvement ideas In-Reply-To: <477D987C.2090806@gmail.com> References: <477D987C.2090806@gmail.com> Message-ID: <477E3D69.5000307@gmail.com> Twan van Laarhoven wrote: > Hello GHC people, > > I was trying my hand at some GHC hacking, and I couldn't help but notice > that much of the code looks (IMHO) horrible. There are some things that > look as if they haven't been touched since the Haskell 1.3 days. The > most striking is the use of `thenXX` instead of do notation. > > I was thinking of cleaning up some of this. In particular: > > 1a. Use do notation where possible instead of `thenXX`. Yes. > 1b. Even better, use Applicative where possible. For example > > ds_type (HsFunTy ty1 ty2) > = dsHsType ty1 `thenM` \ tau_ty1 -> > dsHsType ty2 `thenM` \ tau_ty2 -> > returnM (mkFunTy tau_ty1 tau_ty2) > > Could be rewritten as > > ds_type (HsFunTy ty1 ty2) > = mkFunTy <$> dsHsType ty1 <*> dsHsType ty2 No, IMO. This just adds another abstraction that a potential GHC contributor has to learn about. Including me :-) It doesn't hurt to write out the code in full sometimes, and as the GHC coding style guidelines say: Remember: other people have to be able to quickly understand what you've done, and overuse of abstractions just serves to obscure the really tricky stuff, and there's no shortage of that in GHC. http://hackage.haskell.org/trac/ghc/wiki/Commentary/CodingStyle (I think I might be quoting myself there, in which case it doesn't really add much credibility to my argument :). Also bear in mind that we have to be able to compile GHC with older versions of itself (currently back to 6.2.2), which explains why we're often conservative with respect to using external libraries. > 2. Investigate the need for all these mappM functions. To quote the > source: "Standard combinators, but specialised for this monad (for > efficiency)". Wouldn't a SPECIALIZE pragma work just as well? It does look like we could do away with some of those, yes. > 3. In general, use standard functions when they are available. > Currently GHC has its own sort function and its own versions of > FiniteMap/Data.Map and Text.PrettyPrint. Using standard functions/data > structures will a) make GHC smaller and therefore easier to maintain, > and b) will make the code easier to understand for someone who knows the > standard library. In general yes. But bear in mind there's another principle at work here: we want to insulate GHC as much as possible from its environment, to reduce the chances of spurious failures or performance regressions. I believe our version of Text.PrettyPrint has diverged from the library version - last time I looked it wasn't obvious that we could replace it. Regarding Data.Map, I'd be interested in trying out AVL trees instead, to see if they have better performance, but then we'd have to import the code of course. > 4. A more radical change would be introducing hierarchical modules. > This could be just a matter of renaming the directories to start with an > upper case character and changing the import declarations. This gives > module names like "Typecheck.TcGadt". The tc is redundant here, so > perhaps it should be renamed to "Typecheck.Gadt" or "Typecheck.GADT". > Perhaps even better would be "GHC.Typecheck.GADT", this way some modules > can be exposed as part of the GHC api. Yes, I've wondered about doing this in the past. It does mean more typing, though: clearly 'import BasicTypes.Id' is more painful than just 'import Id' and doesn't add much, so IMO we'd need to put some thought into a structure that makes sense. > How do the GHC developers feel about this? Would such paches be gladly > excepted? Or will they be directly forwarded to the bit bucket? Within the constraints I've outlined above, cleanups are definitely welcome. Another worthwhile gardening-type activity is to go around elimianting warnings. Many modules have {-# OPTIONS -w #-} at the top, waiting for someone to go in and clean up all the warnings. They do catch real bugs, so this is not a waste of time by any means. In addition to this, things like - identifying and removing dead code - commoning up duplicate code fragments - improving test coverage - profiling and optimising hotspots are all useful tasks. Cheers, Simon From ndmitchell at gmail.com Fri Jan 4 09:07:51 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Fri Jan 4 09:01:43 2008 Subject: GHC source code improvement ideas In-Reply-To: <477D987C.2090806@gmail.com> References: <477D987C.2090806@gmail.com> Message-ID: <404396ef0801040607p1e1c4e8cv3913a3ac8e864729@mail.gmail.com> Hi Yhc did a few of these things, and our experiences were: > 1a. Use do notation where possible instead of `thenXX`. If it is that simple, yes. Certainly Yhc uses "super-monads" which made this a bit painful. You should probably step this by getting it to the stage where thenXX = >>=, then only flipping to do notation once the things are already monads. > 1b. Even better, use Applicative where possible. For example > > ds_type (HsFunTy ty1 ty2) > = dsHsType ty1 `thenM` \ tau_ty1 -> > dsHsType ty2 `thenM` \ tau_ty2 -> > returnM (mkFunTy tau_ty1 tau_ty2) > > Could be rewritten as > > ds_type (HsFunTy ty1 ty2) > = mkFunTy <$> dsHsType ty1 <*> dsHsType ty2 I still don't particularly like applicative, it is a bit confusing to me. If you moved to using the Uniplate library, you could then write: descendM dsHsType Shoter, more concise, and probably works for more cases than just HsFunTy - eliminating even more code. I suspect moving to Uniplate would give GHC massive benefits. > 4. A more radical change would be introducing hierarchical modules. This > could be just a matter of renaming the directories to start with an upper > case character and changing the import declarations. This gives module names > like "Typecheck.TcGadt". The tc is redundant here, so perhaps it should be > renamed to "Typecheck.Gadt" or "Typecheck.GADT". Perhaps even better would > be "GHC.Typecheck.GADT", this way some modules can be exposed as part of the > GHC api. We did this in Yhc, and it was really useful just to group files into the same directory. Thanks Neil From simonmarhaskell at gmail.com Fri Jan 4 09:14:55 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Fri Jan 4 09:08:50 2008 Subject: odd GHC 6.8.2 compile failure In-Reply-To: <477D3939.7070405@charter.net> References: <477BD3FC.9010302@charter.net> <477CAB1A.9070409@gmail.com> <477CC84D.2040704@charter.net> <477CCDD8.1080905@gmail.com> <477D3939.7070405@charter.net> Message-ID: <477E3F5F.3070804@gmail.com> Isaac Dupree wrote: > Simon Marlow wrote: >> Isaac Dupree wrote: >>> Simon Marlow wrote: >>>> Isaac Dupree wrote: >>>>> linking the compiled stage2 failed when bootstrapping from 6.6.1, >>>>> with --prefix=$HOME . >>>>> >>>>> It's odd because I previously had a 6.8.2 (official x86 Linux >>>>> bin-dist) installed as root (it's gone now), and I still have a >>>>> bunch of cabal/hackage packages installed in $HOME that were >>>>> compiled by that 6.8.2 (in addition to a few things installed by >>>>> `cabal install` in ~/.cabal/). Do you think that could be >>>>> confusing the build process, and if it is, is that a bug - and a >>>>> bug in what? >>>> >>>> It looks like at some point you've updated your sources and >>>> recompiled without cleaning in stage2, or something similar. The >>>> build system doesn't currently notice when libraries have changed >>>> and stage2 needs to be completely recompiled. >>> >>> It sure looks that way! But I didn't do that personally; I think >>> these are all of my steps: >>> [download via Firefox to /Users/me/downloads/ghc-6.8.2-src.tar.bz2] >>> cd /Users/me/programming/cabalz/NotActuallyCabalButMaybeShouldBe >>> aunpack /Users/me/downloads/ghc-6.8.2-src.tar.bz2 >>> # this `aunpack` is equivalent to tar -xjf in this case. >>> cd ghc-6.8.2 >>> ./configure --prefix=$HOME >>> # ($HOME is /Users/me/HOME , by the way). >>> make >>> >>> Indeed I just reproduced it, newly unpacking that tarball in a new >>> location, to make sure, and I got the same error. >>> >>> >>> What if GHC suddenly decided to link with the newer versions of the >>> boot-libraries than come with 6.8.2, the ones that could be found in >>> $HOME since I installed them there? (or with the _same_ versions that >>> happened to be compiled with different flags, perhaps?) >> >> And you get different results if you omit the --prefix=$HOME? (if so, >> that's very strange, and I don't have a clue what's wrong, yet) > > tested a couple more times: > - it still fails without --prefix=$HOME > - but it succeeds if I `su - east` and have 'east' compile it (without > using --prefix here either) ('east' being another user on my machine > other than the user 'me' which I usually use) Ah, I see. You have packages installed in your home directory for GHC 6.8.2, and these are being picked up by the stage1 compiler. We should be using -no-user-package-conf when running the compiler from the build tree. I'll test this fix. Note however that if you install this compiler, the packages in your home directory won't work any more, because they were compiled by another instance of 6.8.2 against a different set of packages. Cheers, Simon From isaacdupree at charter.net Fri Jan 4 09:24:36 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Fri Jan 4 09:18:30 2008 Subject: odd GHC 6.8.2 compile failure In-Reply-To: <477E3F5F.3070804@gmail.com> References: <477BD3FC.9010302@charter.net> <477CAB1A.9070409@gmail.com> <477CC84D.2040704@charter.net> <477CCDD8.1080905@gmail.com> <477D3939.7070405@charter.net> <477E3F5F.3070804@gmail.com> Message-ID: <477E41A4.20504@charter.net> Simon Marlow wrote: > Note however that if you install this compiler, the packages in your > home directory won't work any more, because they were compiled by > another instance of 6.8.2 true, but doesn't 6.8.2 itself have the same ABI as any other 6.8.2, not counting packages? > against a different set of packages. hmm. different versions? I think it might work out since I installed everything locally, if I just install the versions of the extra-libs that came with the 6.8.2 bindist... Or do I have too great hopes in the reproducibility of ghc compilations? (Not that I have any reason to try that. I would probably just pull from the 6.8-darcs-branch to get your patch (and other post-6.8.2 fixes) and recompile everything anyway.) ~Isaac From simonmarhaskell at gmail.com Fri Jan 4 09:43:15 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Fri Jan 4 09:37:11 2008 Subject: odd GHC 6.8.2 compile failure In-Reply-To: <477E41A4.20504@charter.net> References: <477BD3FC.9010302@charter.net> <477CAB1A.9070409@gmail.com> <477CC84D.2040704@charter.net> <477CCDD8.1080905@gmail.com> <477D3939.7070405@charter.net> <477E3F5F.3070804@gmail.com> <477E41A4.20504@charter.net> Message-ID: <477E4603.5060002@gmail.com> Isaac Dupree wrote: > Simon Marlow wrote: >> Note however that if you install this compiler, the packages in your >> home directory won't work any more, because they were compiled by >> another instance of 6.8.2 > > true, but doesn't 6.8.2 itself have the same ABI as any other 6.8.2, not > counting packages? Yes, the ABI is the same, but there's no guarantee that the interfaces to all the packages are the same. >> against a different set of packages. > > hmm. different versions? I think it might work out since I installed > everything locally, if I just install the versions of the extra-libs > that came with the 6.8.2 bindist... > > Or do I have too great hopes in the reproducibility of ghc compilations? It's too fragile to rely on getting the same results when you compile a package again, if -O is on. In practice, if the conditions are exactly the same you can often get identical interfaces, but we've never put any effort into figuring out how to guarantee this and under what conditions. Better not to rely on it. Cheers, Simon From Christian.Maeder at dfki.de Fri Jan 4 10:38:41 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Jan 4 10:32:34 2008 Subject: Maps, was Re: GHC source code improvement ideas In-Reply-To: <477E3D69.5000307@gmail.com> References: <477D987C.2090806@gmail.com> <477E3D69.5000307@gmail.com> Message-ID: <477E5301.8010700@dfki.de> Simon Marlow wrote: > Regarding Data.Map, I'd be interested in trying out AVL trees instead, > to see if they have better performance, but then we'd have to import the > code of course. Surely, we want the best maps possible for ghc and as public library (and minimize maintenance). The problem is to agree on a suitable interface. I would suggest to take (or only slightly change) Daan's interface (the current Data.Map) and improve the underlying implementation possibly using (i.e. Adrian Hey's) AVL trees. Christian From Christian.Maeder at dfki.de Fri Jan 4 12:03:50 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Jan 4 11:57:43 2008 Subject: binary-dists for ghc-6.8.2 In-Reply-To: <47682317.6030407@dfki.de> References: <47682317.6030407@dfki.de> Message-ID: <477E66F6.3040504@dfki.de> Christian Maeder wrote: > > http://www.dfki.de/sks/hets/mac/versions/ghc-6.8.2-powerpc-apple-darwin.tar.bz2 > http://www.dfki.de/sks/hets/intel-mac/versions/ghc-6.8.2-i386-apple-darwin.tar.bz2 these dists are updated now, with a proper (though stripped) file hsc2hs-bin that caused problems http://hackage.haskell.org/trac/ghc/ticket/1395. > The frameworks under > http://www.haskell.org/ghc/dist/mac_frameworks/mac_e.htm > should do. > The Mac binaries have been built using > gcc version 4.0.1 (Apple Computer, Inc. build 5367) > and a patched Linker.lhs from > http://hackage.haskell.org/trac/ghc/ticket/1798 Also the file compiler/main/DriverPipeline.hs is (still) patched according to http://hackage.haskell.org/trac/ghc/ticket/1395 > The PPC binary still features: > http://hackage.haskell.org/trac/ghc/ticket/1845 Both binaries have a fix for http://hackage.haskell.org/trac/ghc/ticket/1980 now. (Only the PPC dist has been rebuilt, the i386 one was only repacked) Ian, could you replace the dists on the download page? It's possible to overwrite an installation (and loose your later installed packages!), but not necessary in most cases. Still use "make install-strip" after "./configure". Christian From igloo at earth.li Fri Jan 4 12:47:39 2008 From: igloo at earth.li (Ian Lynagh) Date: Fri Jan 4 12:41:31 2008 Subject: GHC source code improvement ideas In-Reply-To: References: <477D987C.2090806@gmail.com> Message-ID: <20080104174739.GA8322@matrix.chaos.earth.li> On Fri, Jan 04, 2008 at 08:34:22AM +0000, Simon Peyton-Jones wrote: > > | 4. A more radical change would be introducing hierarchical modules. This > | could be just a matter of renaming the directories to start with an upper > | case character and changing the import declarations. This gives module names > | like "Typecheck.TcGadt". The tc is redundant here, so perhaps it should be > | renamed to "Typecheck.Gadt" or "Typecheck.GADT". Perhaps even better would > | be "GHC.Typecheck.GADT", this way some modules can be exposed as part of the > | GHC api. > > I don't think I'd object, but I'm not sure that much is gained here. We don't spend much time on mondule-name clashes. One point is that GHC uses module names like Util and State, which is a bit unfriendly to people using GHC-as-a-library. Also, although "import Types.Generics" is a bit longer to type, it is also a bit easier for someone less familiar with the code to follow the imports (if their editor does not help them). It's a pity that GHC.* is already used in base. I'm not sure what the best thing to do is in the short term. Thanks Ian From kili at outback.escape.de Fri Jan 4 15:54:45 2008 From: kili at outback.escape.de (Matthias Kilian) Date: Fri Jan 4 15:48:54 2008 Subject: GHC 6.8.1 port on FreeBSD-amd64? In-Reply-To: References: Message-ID: <20080104205445.GA30327@petunia.outback.escape.de> [Note: already shortly discussed with Wilhelm] On Fri, Nov 23, 2007 at 12:30:06PM +0000, Wilhelm B. Kloke wrote: > > ../../compiler/stage1/ghc-inplace -package-name unix-2.2.0.0 -hide-all-packages -i -idist/build/autogen -idist/build -i. -Idist/build -Iinclude -#include "HsUnix.h" -#include "execvpe.h" -odir dist/build -hidir dist/build -stubdir dist/build -package base-3.0.0.0 -package directory-1.0.0.0 -O -XCPP -XForeignFunctionInterface -idist/build -H32m -O0 -fasm -Rghc-timing -keep-hc-files -O -c dist/build/System/Posix/Process.hs -o dist/build/System/Posix/Process.o -ohi dist/build/System/Posix/Process.hi > > Prologue junk?: .type s32x_ret, @function > > s32x_ret: > > pushl %ebp > > movl %esp, %ebp I see nearly the same problem with ghc-6.8.2 on OpenBSD, using the gcc-3.3.5 included in its base system. Regardless of wether there's something wrong with the generated code or wether it's just a bug in the mangler, it's possible to build Process.c with -fviaC *and* -O0.[1] For now, I'm able to build a HC file bundle with this settings in build.mk and running "gmake stage1 hc-file-bundle": SRC_HC_OPTS= -H64 -O -fvia-C -keep-hc-files GhcLibHcOpts= -O0 # Workaround the mangler problem GhcLibWays= GhcRTSWays= SplitObjs= NO I'd appreciate any reports wether people see the same problem on other systems (if so: what gcc version are you using?) and wether GhcLibHcOpts=-O0 fixes it. Ciao, Kili [1] BTW: what's the point of using -fasm with -keep-hc-files? IMHO, it should be -fviaC -keep-hc-files. Someone let me know if I should correct this in the wiki. ps: yes, I'm slowly trying to bring HC bootstrap back to work. It's a must-have for the OpenBSD port. Apart from the HC file bundle, this will require some more hacking especially on library/Makefile and the Cabal-generated GNUmakefiles (and/or Makefile.local). pps: I guess, cvs-ghc would be the more correct list for sending patches and discussing the bootstrapping stuff, right? From brianh at metamilk.com Fri Jan 4 19:26:41 2008 From: brianh at metamilk.com (Brian Hulley) Date: Fri Jan 4 19:17:03 2008 Subject: Module system, was Re: GHC source code improvement ideas In-Reply-To: <20080104174739.GA8322@matrix.chaos.earth.li> References: <477D987C.2090806@gmail.com> <20080104174739.GA8322@matrix.chaos.earth.li> Message-ID: <477ECEC1.8000109@metamilk.com> Ian Lynagh wrote: > On Fri, Jan 04, 2008 at 08:34:22AM +0000, Simon Peyton-Jones wrote: >> | 4. A more radical change would be introducing hierarchical modules. >> > > It's a pity that GHC.* is already used in base. I'm not sure what the > best thing to do is in the short term. > How about Language.Haskell.Compiler.GHC.* In the long term, Haskell needs a better module system IMHO, since the problem at the moment is that having to write the full hierarchical name in each module means that you need to know in advance, before you've even started writing a program, where each module will fit into the global namespace, which makes it extraordinarily difficult to do exploratory programming or bottom-up development, and the need to write so many import directives in each module makes it extremely painful not to mention overly hard-wired. A good direction IMHO is the way SML structures are grouped using CM.make (SML/NJ) or MLBasis (MLton and others), so that there are no import directives at all: a separate group definition determines what is in scope, and compilation proceeds by chasing these group definition files rather than chasing modules. Translating this into Haskell, the module syntax could be simplified and other modules could be nested and aliased within a module, so that it is easy to create different hierarchical views of the modules which are in scope to suit the particular module being written or clients of that module: -- Leaf.hs module Leaf where module String where open Data.ByteString.Char8 type T = ByteString module Map = Data.Map module Util where foo :: Int -> Int foo i = i --Other.hs module Other where bar :: Int -> Leaf.String.T bar = Leaf.String.pack . show . Leaf.Util.foo Note that here there is no need for any import directives, since the modules which are in scope when Leaf.hs is compiled would be determined by whatever group Leaf.hs is part of (with respect to that particular program), which would be defined in a separate file: --MyBasis.hsg local $Haskell/StdBase.hsg Leaf.hs Other.hs Within the .hsg files, groups and modules are referenced by filename, and is just a simple list of components that are required and/or exported by the group. In the .hsg file above, MyBasis will export the contents of Leaf.hs and Other.hs, which are compiled in an environment augmented by StdBase (which is not itself exported by MyBasis). (See CM.make and the MLBasis system for more details - in particular, for any given program a module may appear in only one group, but the same module may appear in different groups in different programs thus facilitating easy exploratory programming and re-organization without breaking previous programs.) This can be taken further to get an even more powerful system by using parameterized traits and explicit instantiation for modules: trait T a b where foo :: a -> b bar :: Int -> Int bar i = i + 1 module M where include T Int String foo = show . bar Here, the body of a module is always a trait, and the above is equivalent to: trait T a b = tra foo :: a -> b bar :: Int -> Int bar i = i + 1 module M = new tra include T Int String foo = show . bar which makes it more explicit that conversion of the contents to actual code (ie linking, allocation/identity/initialization of CAFs and foreign objects, generativity of data types etc) happens only in the module decl. The great thing about making instantiation explicit is that traits are pure functional values and so can easily be combined with no side effects, whereas modules may in general contain mutable state eg to interface with some external C library and thus are objects-with-identity. Thus the separation solves the whole problem of applicative vs generative functors in ML, as well as solving the problem of mutually recursive structures (functors become a redundant concept because you can always start with including a trait then overriding some decls with more instantiated (here used in a different sense) decls and/or traits). Last but not least, a trait could also be used similarly to a signature, except that definitions in the trait can be considered to be default implementations. Therefore in this scenario the body of a class or instance decl is just a trait and so could be composed using other traits etc. (Each instance decl instantiates the trait given in the body merged with the trait given in the class leading to a possibly parameterized module.) Anyway these are some of the directions I am currently working on for my new language which is a strict version of Haskell/ML but where explicit type annotations drive name resolution rather than explicit namespace annotations driving type inference. Related work for the above version of traits/mixins includes the Scala language and the approach described in "Evolving Software with Extensible Modules" by Matthias Zenger. Regards, Brian. -- www.metamilk.com From isaacdupree at charter.net Fri Jan 4 20:24:32 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Fri Jan 4 20:18:25 2008 Subject: wish for more-usable bindist Message-ID: <477EDC50.10308@charter.net> the i386 linux ghc bindist still uses readline 4 , which is hard to get: readline 5.0 came out almost three and a half years ago And I don't want to pollute my Ubuntu system with "compatibility RPMs"; in fact I intend to install the bindist as my local user so I don't pollute it with extra GHCs either, except I can't. Could there be a bindist with modern readline, or perhaps is it possible to statically link with readline? ~Isaac From brianh at metamilk.com Fri Jan 4 21:02:09 2008 From: brianh at metamilk.com (Brian Hulley) Date: Fri Jan 4 20:52:30 2008 Subject: Module system, was Re: GHC source code improvement ideas In-Reply-To: <477ECEC1.8000109@metamilk.com> References: <477D987C.2090806@gmail.com> <20080104174739.GA8322@matrix.chaos.earth.li> <477ECEC1.8000109@metamilk.com> Message-ID: <477EE521.1010207@metamilk.com> Brian Hulley wrote: > Ian Lynagh wrote: >> On Fri, Jan 04, 2008 at 08:34:22AM +0000, Simon Peyton-Jones wrote: >>> | 4. A more radical change would be introducing hierarchical modules. >>> Sorry I quoted what Simon PJ replied to not what he wrote so I should have written: > Ian Lynagh wrote: >> >>> On Fri, Jan 04, 2008, Twan van Laarhoven wrote: >>> 4. A more radical change would be introducing hierarchical modules. Though this is again not quite right since Ian did not write line 3... Apologies to Simon PJ and Twan (and now also to Ian) for mis-quoting ;-) Brian. From isaacdupree at charter.net Fri Jan 4 21:36:33 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Fri Jan 4 21:30:26 2008 Subject: there isn't any difference, is there, with unboxed tuples? Message-ID: <477EED31.6050802@charter.net> --> unboxed types in function results are automatically "lifted"... or what was the term meaning they could be _|_, failing to terminate, (because of the function-ness)? --> unboxed tuples are specially restricted to be only allowed, among useful places, in function results. Therefore (... -> ( a, b, c ) ) and (... -> (# a, b, c #)) are identical, assuming both are kind-correct (identical in terms of optimization and semantics, not type equality, of course). Is that right? If so, there's never an excuse to use unboxed tuples except to contain unboxed values (because then you don't have the choice of using boxed tuples, which can only contain boxed values of kind *). ~Isaac From stefanor at cox.net Fri Jan 4 21:55:30 2008 From: stefanor at cox.net (Stefan O'Rear) Date: Fri Jan 4 21:49:23 2008 Subject: there isn't any difference, is there, with unboxed tuples? In-Reply-To: <477EED31.6050802@charter.net> References: <477EED31.6050802@charter.net> Message-ID: <20080105025530.GA5339@localhost.localdomain> On Fri, Jan 04, 2008 at 09:36:33PM -0500, Isaac Dupree wrote: > --> unboxed types in function results are automatically "lifted"... or what > was the term meaning they could be _|_, failing to terminate, (because of > the function-ness)? > > --> unboxed tuples are specially restricted to be only allowed, among > useful places, in function results. > > Therefore (... -> ( a, b, c ) ) and (... -> (# a, b, c #)) are identical, > assuming both are kind-correct (identical in terms of optimization and > semantics, not type equality, of course). Is that right? If so, there's > never an excuse to use unboxed tuples except to contain unboxed values > (because then you don't have the choice of using boxed tuples, which can > only contain boxed values of kind *). Semantically, you are absolutely correct. However, there is a very subtle difference in sharing. Consider these two functions: foo (a,b) = (a,b) bar tuple = tuple These two functions are denotationally identical, but at runtime one performs more allocations. If we use unboxed tuples, then the caller must always allocate if a tuple is needed; thus effectively we always get the allocation behavior of foo. That is, return unboxing is not always an optimization! However, it *is* always safe if the tuple is constructed in the function itself, for then it could not possibly be shared with anything. Having explicit unboxed tuples in the language allows this complexity to be moved out of the code generator, which is a Good Thing. (Incidentally, this is what the CPR analysis is all about - identifying places where a Constructed Product is Returned.) Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080104/8d840154/attachment.bin From isaacdupree at charter.net Sat Jan 5 05:45:38 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Sat Jan 5 05:39:28 2008 Subject: there isn't any difference, is there, with unboxed tuples? In-Reply-To: <20080105025530.GA5339@localhost.localdomain> References: <477EED31.6050802@charter.net> <20080105025530.GA5339@localhost.localdomain> Message-ID: <477F5FD2.1090408@charter.net> Stefan O'Rear wrote: > Semantically, you are absolutely correct. However, there is a very > subtle difference in sharing. > > Consider these two functions: > > foo (a,b) = (a,b) > bar tuple = tuple > > These two functions are denotationally identical, but at runtime one > performs more allocations. If we use unboxed tuples, then the caller > must always allocate if a tuple is needed; thus effectively we always > get the allocation behavior of foo. That is, return unboxing is not > always an optimization! However, it *is* always safe if the tuple is > constructed in the function itself, for then it could not possibly be > shared with anything. Having explicit unboxed tuples in the language > allows this complexity to be moved out of the code generator, which is a > Good Thing. (Incidentally, this is what the CPR analysis is all about - > identifying places where a Constructed Product is Returned.) hmm. so it might have to be some hypothetical syntax like (... -> {-#UNPACK#-} (a, b)) when in a data type (for some monad definition in GHC's code, so I don't want to lose performance by boxing it). (Either that or it might actually be more efficient if it were boxed!) Am I right that CPR analysis can look at particular functions, but there's no way for it to change the representation of a function stored in a data/newtype? ~Isaac From ndmitchell at gmail.com Sat Jan 5 09:47:18 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sat Jan 5 09:41:06 2008 Subject: Redefining built in syntax In-Reply-To: References: <404396ef0712310858l44c73920s284b5c738c5b776e@mail.gmail.com> <404396ef0801031029u2434294u79867a1a10c587c@mail.gmail.com> Message-ID: <404396ef0801050647r43cd5312qd41c97e3dae52c4b@mail.gmail.com> Hi > I don't think we'd ever thought of doing this. In particular, I don't think we'd every considered using GHCi in combination with -package-name. > > The immediate problem is that GHCi looks for the value "System.IO.stdout" so that it can use it to print things, and it can't find module System.IO, I think because you've overridden the base-package binding. > > > Do you have to use GHCi for this stuff? It's delicate, because GHCi prints things, but you want to compile the very functions it is using to do the printing... I think in consultation with Tim (many thanks!) I've figured out why things aren't working, and how I can lightly hack around the problem. The first issue seems to be that I'm trying to compile modules from the base library source against preinstalled versions, not versions I've built myself - meaning I lack .hi-boot files. The second issue seems to concern various flags and meanings of flags. What I'm doing is clearly well beyond anything that was ever contemplated, but is working near enough that I can use it to do the next stages. Once I have everything a bit more stabalised, I'll post up my code and my intentions and try and classify the exact issues I am running into. Thanks Neil From igloo at earth.li Sat Jan 5 11:01:09 2008 From: igloo at earth.li (Ian Lynagh) Date: Sat Jan 5 10:54:57 2008 Subject: binary-dists for ghc-6.8.2 In-Reply-To: <477E66F6.3040504@dfki.de> References: <47682317.6030407@dfki.de> <477E66F6.3040504@dfki.de> Message-ID: <20080105160109.GA18866@matrix.chaos.earth.li> On Fri, Jan 04, 2008 at 06:03:50PM +0100, Christian Maeder wrote: > Christian Maeder wrote: > > > > http://www.dfki.de/sks/hets/mac/versions/ghc-6.8.2-powerpc-apple-darwin.tar.bz2 > > http://www.dfki.de/sks/hets/intel-mac/versions/ghc-6.8.2-i386-apple-darwin.tar.bz2 > > Ian, could you replace the dists on the download page? Done; I assume that these dists include the new hsc2hs-bin from http://www.haskell.org/pipermail/glasgow-haskell-users/2008-January/013998.html ? Thanks Ian From naur at post11.tele.dk Sat Jan 5 13:29:49 2008 From: naur at post11.tele.dk (Thorkil Naur) Date: Sat Jan 5 13:24:41 2008 Subject: http://www.haskell.org/ghc/dist/mac_frameworks/GNUreadline-framework.zip In-Reply-To: <20080104110313.BDBB4584.fep28.mail.dk@smtprelay07.ispgateway.de> References: <477CE624.3040806@dfki.de> <200801032058.47615.naur@post11.tele.dk> <20080104110313.BDBB4584.fep28.mail.dk@smtprelay07.ispgateway.de> Message-ID: <200801051929.51180.naur@post11.tele.dk> Hello, On Friday 04 January 2008 12:03, Christian Maeder wrote: > ... Thanks a lot for this response. > I'm not happy about this framework hick-hack either. I am glad we agree about that. > I've only pushed > it, because we needed a readline solution on macs. I understand that there are problems in this area, but I am not convinced that they could not be solved without the renamed and/or modified readline library. I am sorry if you have done that already elsewhere, but I don't recall having seen any details about your difficulties. Would you be kind enough to supply some details? Thanks a lot. > The alternative is to use static linking of gmp (as suggested by chak) > _and_ readline (version 5), so that user programs are also statically > linked with these libs. Again, I am not convinced that this is the only alternative. > ... > Regarding this actual GNUreadline-framework.zip replacement, this is > harmless and seems to matter only for those who build ghc with > frameworks (as only the inclusion of header files changed) It is perhaps without any practical consequences, but I have seen many cases where circumstances managed to create the most glorious confusion out of the most innocently looking changes. So I would maintain that replacing something that you have published with something different is not a good idea. > > In any case we should strive to fix the frameworks issues _and_ add > support for static linking of gmp, readline and possibly other libs > (plus license issues). I fully agree with this. Ideally, the plan would be to, first, figure out what the ideal solution looks like. And then work towards that ideal solution. Making sure that what we introduce on the way as short-term hacks are clearly marked as such, to ensure that they don't impress themselves on people's minds as part of the final solution. I have every intention to work out some ideal (or perhaps more modestly: better) solution. But whether it will emerge in time to make any difference, remains to be seen. > > HTH Christian Thanks and best regards Thorkil From ndmitchell at gmail.com Sat Jan 5 15:00:44 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sat Jan 5 14:54:32 2008 Subject: GHC Core question Message-ID: <404396ef0801051200m3511c04ai507720bdcf1ae386@mail.gmail.com> Hi I've compiled the Debug.Trace module to Core, but can't understand the resulting output. The original code is: trace string expr = unsafePerformIO $ do putTraceMsg string return expr The core is: Debug.Trace.trace = \ (@ a) -> __letrec { trace :: GHC.Base.String -> a -> a [] trace = \ (string :: GHC.Base.String) (expr :: a) -> GHC.Base.$ @ (GHC.IOBase.IO a) @ a (GHC.IOBase.unsafePerformIO @ a) (>> @ () @ a (Debug.Trace.putTraceMsg string) (return @ a expr)); $dMonad :: GHC.Base.Monad GHC.IOBase.IO [] $dMonad = $dMonad; return :: forall a. a -> GHC.IOBase.IO a [] return = GHC.Base.return @ GHC.IOBase.IO $dMonad; $dMonad :: GHC.Base.Monad GHC.IOBase.IO [] $dMonad = GHC.IOBase.$f16; >> :: forall a b. GHC.IOBase.IO a -> GHC.IOBase.IO b -> GHC.IOBase.IO b [] >> = GHC.Base.>> @ GHC.IOBase.IO $dMonad; } in trace; And my Haskell reformatting of that is: Debug.Trace.trace = let trace string expr = unsafePerformIO $ putTraceMsg string >> return expr $dMonad = $dMonad; return = GHC.Base.return $dMonad; $dMonad = GHC.IOBase.$f16; >> = GHC.Base.>> $dMonad; in trace However, that let expression has two bindings for $dMonad, one of which looks like a black-hole. Are the semantics of __letrec different from let in some way? Thanks Neil From judah.jacobson at gmail.com Sat Jan 5 15:23:59 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Sat Jan 5 15:17:48 2008 Subject: http://www.haskell.org/ghc/dist/mac_frameworks/GNUreadline-framework.zip In-Reply-To: <200801051929.51180.naur@post11.tele.dk> References: <477CE624.3040806@dfki.de> <200801032058.47615.naur@post11.tele.dk> <20080104110313.BDBB4584.fep28.mail.dk@smtprelay07.ispgateway.de> <200801051929.51180.naur@post11.tele.dk> Message-ID: <6d74b0d20801051223gc73ee49pff3b9ece85177e83@mail.gmail.com> On Jan 5, 2008 10:29 AM, Thorkil Naur wrote: > On Friday 04 January 2008 12:03, Christian Maeder wrote: > > I understand that there are problems in this area, but I am not convinced that > they could not be solved without the renamed and/or modified readline > library. I am sorry if you have done that already elsewhere, but I don't > recall having seen any details about your difficulties. Would you be kind > enough to supply some details? Thanks a lot. > > > The alternative is to use static linking of gmp (as suggested by chak) > > _and_ readline (version 5), so that user programs are also statically > > linked with these libs. > > Again, I am not convinced that this is the only alternative. There is another alternative (which I think we talked about before): Have ghc manually search for frameworks in the standard folders (rather than letting gcc do it automatically). Then if we found e.g. /Library/Frameworks/GNUreadline.framework, we would pass the following flag: -I/Library/Frameworks/GNUreadline.framework/Versions/A/Headers In that case, we would not need modified readline headers. However, I really don't like the above, since we're reimplenting something gcc gives us for free. And if we *do* rely on gcc's standard searching (as is the case now), then I agree with Christian that modified headers are necessary for GNUreadline to work as a framework. Also, the script that builds GNUreadline.framework modifies the header files automatically. So I don't think it's any worse than, say, pre-processing a library as part of a MacPorts distribution. > > ... > > Regarding this actual GNUreadline-framework.zip replacement, this is > > harmless and seems to matter only for those who build ghc with > > frameworks (as only the inclusion of header files changed) > > It is perhaps without any practical consequences, but I have seen many cases > where circumstances managed to create the most glorious confusion out of the > most innocently looking changes. So I would maintain that replacing something > that you have published with something different is not a good idea. I looked into this, and frameworks do already support versioning: http://developer.apple.com/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/VersionInformation.html In particular, one framework can contain multiple versions. So currently GNUreadline.framework contains: Versions/A/GNUreadline (object code file) Versions/A/Headers (a folder containing header files) GNUreadline (symlink to `Versions/A/GNUreadline`) Headers (symlink to `Versions/A/Headers`) And we could distribute instead a GNUreadline.framework which contains: Versions/A/GNUreadline (object code file) Versions/B/GNUreadline (symlink to the above) GNUreadline (symlink to Versions/A/GNUreadline) Versions/A/Headers (a folder containing unmodified headers) Versions/B/Headers (a folder containing modified headers) Headers (symlink to Versions/B/Headers) The above makes version B the default, but version A is still available if you want it. We could do something similar when upgrading to readline 6.0 if it ever comes out. Finally, we could also change the name of the .zip file to reflect the version of the framework, so that users don't confuse the two downloads. Would the above make the modified GNUreadline feel like less of a hack? Best, -Judah From evas at mountaincable.net Sat Jan 5 15:38:58 2008 From: evas at mountaincable.net (Chris Saunders) Date: Sat Jan 5 15:34:20 2008 Subject: binary-dists for ghc-6.8.2 In-Reply-To: <20080105160109.GA18866@matrix.chaos.earth.li> References: <47682317.6030407@dfki.de> <477E66F6.3040504@dfki.de> <20080105160109.GA18866@matrix.chaos.earth.li> Message-ID: <000601c84fda$ff6abff0$fe403fd0$@net> Will there be a binary release for Windows x86_64? Regards Chris Saunders From waldmann at imn.htwk-leipzig.de Sat Jan 5 17:28:16 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Sat Jan 5 17:22:04 2008 Subject: Module system, was Re: GHC source code improvement ideas In-Reply-To: <477ECEC1.8000109@metamilk.com> References: <477D987C.2090806@gmail.com> <20080104174739.GA8322@matrix.chaos.earth.li> <477ECEC1.8000109@metamilk.com> Message-ID: <47800480.7050808@imn.htwk-leipzig.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brian Hulley wrote: > In the long term, Haskell needs a better module system IMHO [...] I agree with the symptoms that were described, but I draw a different conclusion. We don't need to change the language - we need better tools (IDEs) that operate not at the textual level, but use the annotated syntax tree, including knowledge on fully qualified names and types. E.g. Java requires to write full package names everywhere, but this is never a problem when working with Eclipse (or any other modern IDE I assume) since it just knows how to rename a package or move a class etc. Try moving some Haskell functions/declarations by hand (e.g. with Emacs) into a different, or a new module. It's a nightmare until you get all the imports and qualified usages right. But it really is conceptually simple, so it should be a one-click operation. Since it's this time of the year, here's my wish for 2008: a version of HaRe (Haskell Refactorer) that knows current ghc language extensions *and is integrated with Eclipse* The way to go seems this: http://eclipsefp.sourceforge.net/cohatoe/ and I dearly hope there will be more progress on that. Best regards, Johannes Waldmann, Leipzig. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHgAR23ZnXZuOVyMIRAvYsAJ9DRhuJ3Nxyn+L+elwij5YmqWw89wCgrtLX tBgzlnLUjkNWqPkZgCykLuk= =I3TR -----END PGP SIGNATURE----- From ahey at iee.org Sun Jan 6 07:37:53 2008 From: ahey at iee.org (Adrian Hey) Date: Sun Jan 6 07:31:40 2008 Subject: Maps, was Re: GHC source code improvement ideas In-Reply-To: <477E5301.8010700@dfki.de> References: <477D987C.2090806@gmail.com> <477E3D69.5000307@gmail.com> <477E5301.8010700@dfki.de> Message-ID: <4780CBA1.4040907@iee.org> Christian Maeder wrote: > Simon Marlow wrote: >> Regarding Data.Map, I'd be interested in trying out AVL trees instead, >> to see if they have better performance, but then we'd have to import the >> code of course. > > Surely, we want the best maps possible for ghc and as public library > (and minimize maintenance). > > The problem is to agree on a suitable interface. I would suggest to take > (or only slightly change) Daan's interface (the current Data.Map) and > improve the underlying implementation possibly using (i.e. Adrian Hey's) > AVL trees. The trouble is as far as implementations is concerned the best maps possible is a continually moving target I suspect, not to mention being highly dependent on key type. I certainly wouldn't say AVL tree based Maps are best possible, though they do seem give better performance (particularly for union, intersection etc..). The clone also address some defects in the current Data.Map (like lack of strictness control) and has some other useful stuff. But if this is going to be used at all, I would say this is only a stop gap solution, which leads me to your second point about interfaces. The generalised trie lib I was working on was a serious attempt to see what a real useable non-toy map API should look like. It's the GT class here.. http://code.haskell.org/collections/collections-ghc6.8/Data-Trie-General/Data/Trie/General/Types.hs (Sorry for the long URL). It's already somewhat huge and still incomplete IMO, but even in it's current form it gives a uniform API for Ints, arbitrary Ord instances and Lists. It's a shame it's all completely untested :-( What really needs to happen on this is.. 1 - "Finish" and stabilise the GT class definition. There's still more that's needed but I think the promised type families magic is needed first. 2 - Write a comprehensive test/benchmarking suite for GT instances. 3 - Provide some way to automatically generate the instances for arbitrary user defined types. Which is all rather a lot of work that nobody seems very interested in :-( Regards -- Adrian Hey From jbapple+ghc-users at gmail.com Sun Jan 6 11:20:42 2008 From: jbapple+ghc-users at gmail.com (Jim Apple) Date: Sun Jan 6 11:14:27 2008 Subject: Rank-2 polymorphism and pattern matching In-Reply-To: References: Message-ID: On Jan 4, 2008 5:15 AM, Simon Peyton-Jones wrote: > | > The following won't compile for me > | > > | > isnull :: (forall a . [a]) -> Bool > | > isnull ([] :: forall b . [b]) = True > | > > | > Couldn't match expected type `forall b. [b]' > | > against inferred type `[a]' > | > In the pattern: [] > > This is a pretty strange thing to do, to match a polymorphic argument against a data constructor. I guess you'd expect this to work too, perhaps? > > f :: forall a. (forall b. Either a b) -> a > f (Left x) = x > > I grant that arguably these should work, but I think it'd be quite tricky to make it do so, because it'd involve re-generalising in the pattern. Furthermore, I can't see any use for it. Just remove the type signature from the pattern. > > One could argue that it's a bad sign that the pattern typechecker should have difficulty with this. But until it turns out to be important I'm not going to lose sleep over it! This is literate Haskell. It's in the LaTeX style, since my mail reader won't change the quoting mark from '>'. It is not a valid LaTeX file. My reason for wanting pattern matching on values of polymorphic types is a kind of first-level refinement types. I'm going to demonstrate using the "risers" function, as presented in Dana N. Xu's ESC/Haskell (http://research.microsoft.com/Users/simonpj/papers/verify/escH-hw.ps or http://www.cl.cam.ac.uk/~nx200/research/escH-hw.ps ), which references Neil Mitchell's Catch (http://www-users.cs.york.ac.uk/~ndm/catch/ ). I'll also be referencing an example from Tim Freeman's thesis on refinement types for ML (http://www.cs.ucla.edu/~palsberg/tba/papers/freeman-thesis94.pdf ) \begin{code} {-# OPTIONS -fglasgow-exts #-} -- The LANGUAGE pragma is usually a pain for exploratory programming. \end{code} This is the risers function, as presented by Xu. It returns the sorted sublists of a list. None of the lists in the return value are empty, and if the argument is non-empty, the return value is also non-empty. \begin{code} risersXu :: (Ord t) => [t] -> [[t]] risersXu [] = [] risersXu [x] = [[x]] risersXu (x:y:etc) = let ss = risersXu (y : etc) in case x <= y of True -> (x : (head ss)) : (tail ss) False -> ([x]) : ss \end{code} Xu uses head and tail. These are safe here by a proof created by ESC/Haskell. Here is the risers function according to Mitchell: \begin{code} risersMitchell :: Ord a => [a] -> [[a]] risersMitchell [] = [] risersMitchell [x] = [[x]] risersMitchell (x:y:etc) = if x <= y then (x:s):ss else [x]:(s:ss) where (s:ss) = risersMitchell (y:etc) \end{code} The unsafe part here is the pattern in the where clause. Mitchell presents a tool to prove this safe. These unsafe operations depend on the second property of the function: non-null inputs generate non-null outputs. We could write a type for this functions using a trusted library with phantom types for branding (http://okmij.org/ftp/Computation/lightweight-dependent-typing.html ). This technique (called lightweight static capabilities) can do this and much else, as well, but clients lose all ability to pattern match (even in case). We could also write a type signature guaranteeing this by using GADTs. Without either one of these, incomplete pattern matching or calling unsafe head and tail on the result of the recursive call seems inevitable. Here's another way to write the function which does away with the need for second property on the recursive call, substituting instead the need for the first property, that no lists in the return value are empty: \begin{code} risersAlt :: (Ord t) => [t] -> [[t]] risersAlt [] = [] risersAlt (x:xs) = case risersAlt xs of [] -> [[x]] w@((y:ys):z) -> if x <= y then (x:y:ys):z else ([x]):w ([]:_) -> error "risersAlt" \end{code} The error is never reached. Though ensuring the second property with our usual types seems tricky, ensuring the first is not too tough: \begin{code} type And1 a = (a,[a]) risersAlt' :: Ord a => [a] -> [And1 a] risersAlt' [] = [] risersAlt' (x:xs) = case risersAlt' xs of [] -> [(x,[])] w@(yys:z) -> if x <= fst yys then (x,fst yys : snd yys):z else (x,[]):w \end{code} It is now much easier to see that risers is safe: There is one pattern match and one case, and each is simple. No unsafe functions like head or tail are called. It does have two disadvantages. First, the second property is still true, but the function type does not enforce it. This means that any other callers of risers may have to use incomplete pattern matching or unsafe functions, since they may not be so easy to transform. It is my intuition that it is not frequently the case that these functions are tricky to transform, but perhaps Neil Mitchell disagrees. We could fix this by writing another risers function with type And1 a -> And1 (And1 a), but this brings us to the second problem: And1 a is not a subtype of [a]. This means that callers of our hypothetical other risers function (as well as consumers of the output from risersAlt') must explicitly coerce the results back to lists. Let's write more expressive signatures using the principle from my original question. \begin{code} data List a n = Nil n | forall r . a :| (List a r) \end{code} [] is the only value of type forall a . [a], assuming no values of type forall a . a. Similarly, the only values of type forall a . List a n use the Nil constructor, and the only values of type forall n . List a n use the :| constructor. \begin{code} infixr :| box x = x :| Nil () type NonEmpty a = forall n . List a n onebox :: NonEmpty Int onebox = box 1 onebox' :: List Int Dummy onebox' = onebox data Dummy -- This doesn't compile -- empty :: NonEmpty a -- empty = Nil () \end{code} NonEmpty a is a subtype of List a x for all types x. Now we get to the disappointing part of the show in which I pine for first-class existentials and pattern matching on polymorphic values. \begin{code} data Some f a = forall n . Some (f a n) safeHead :: NonEmpty a -> a safeHead x = unsafeHead x where unsafeHead (x :| _) = x safeTail :: NonEmpty a -> Some List a safeTail x = unsafeTail x where unsafeTail (_ :| xs) = Some xs \end{code} Unfortunately, we'll be forced to Some and un-Some some values, and it takes some thinking to see that safeHead and safeTail are actually safe. \begin{code} risersMitchell' :: Ord a => List a n -> List (NonEmpty a) n risersMitchell' (Nil x) = (Nil x) risersMitchell' (x :| Nil _) = box (box x) risersMitchell' ((x {- :: a -}) :| y :| etc) = case risersMitchell' (y :| etc) {- :: NonEmpty (NonEmpty a) -} of Nil _ -> error "risersMitchell'" s :| ss -> if x <= y then (x :| s) :| ss else (box x) :| s :| ss \end{code} Since we can't put the recursive call in a where clause, we must use a case with some dead code. The type annotations are commented out here to show they are not needed, but uncommenting them shows that the recursive call really does return a non-empty lists, and so the Nil case really is dead code. This type signature ensures both of the properties listed when introducing risers. The key to the non-empty-arguments-produce-non-empty-results property is that the variable n in the signature is used twice. That means applying risersMitchell' to a list with a fixed (or existential) type as its second parameter can't produce a NonEmpty list. \begin{code} risersXu' :: Ord a => List a r -> List (NonEmpty a) r risersXu' (Nil x) = Nil x risersXu' (x :| Nil _) = box (box x) risersXu' (x :| y :| etc) = let ss = risersXu' (y :| etc) in case x <= y of True -> case safeTail ss of Some v -> (x :| (safeHead ss)) :| v False -> (box x) :| ss \end{code} Here we see that the type annotation isn't necessary to infer that risers applied to a non-empty list returns a non-empty list. The value ss isn't given a type signature, but we can apply safeHead and safeTail. The case matching on safeTail is the pain of boxing up existentials. This is the first version of risers with a type signature that gives us the original invariant Xu and Mitchell can infer, as well as calling no unsafe functions and containing no incomplete case or let matching. It also returns a list of lists, just like the original function. With first-class existentials, this would look just like Xu's risers (modulo built-in syntax for lists). With pattern matching for polymorphic values, risersMitchell' would look just like Mitchell's original risers, but be safe by construction. Pattern matching for polymorphic values would also allow non-trusted implementations of safeTail and safeHead to be actually safe. Since GADTs and lightweight static capabilities are already available, I do not know how compelling this example is. I think there are much more compelling examples for first-class existentials. In any case, here's one more example, this one from Freeman's thesis on refinement types. We create a type of boolean expressions with variables. We can evaluate terms without any free variables, so we distinguish them using the trick above. Unfortunately, this time the constructor restriction isn't just at the top level, but all the way down. We must, therefore, parameterize the recursion in the data type. \begin{code} data BoolExp' a r = And r r | Or r r | Not r | Tru | Fals | Var a String newtype Mu' f = Mu' (forall a . f a (Mu' f)) type Ground = Mu' BoolExp' data Mu f = forall a . Mu (f a (Mu f)) type BoolExp = Mu BoolExp' type Base = forall a r . BoolExp' a r eval :: Ground -> Base eval (Mu' x) = case x of And y z -> case (eval y,eval z) of (Tru,x) -> x _ -> Fals Or y z -> case (eval y,eval z) of (Fals,x) -> x _ -> Tru Not y -> case eval y of Tru -> Fals _ -> Tru Tru -> Tru Fals -> Fals _ -> error "eval" \end{code} The error in eval is never reached. Unfortunately, Ground is not a subtype of BoolExp, so this seems like a less compelling example. From igloo at earth.li Sun Jan 6 11:28:56 2008 From: igloo at earth.li (Ian Lynagh) Date: Sun Jan 6 11:22:42 2008 Subject: binary-dists for ghc-6.8.2 In-Reply-To: <000601c84fda$ff6abff0$fe403fd0$@net> References: <47682317.6030407@dfki.de> <477E66F6.3040504@dfki.de> <20080105160109.GA18866@matrix.chaos.earth.li> <000601c84fda$ff6abff0$fe403fd0$@net> Message-ID: <20080106162856.GA16507@matrix.chaos.earth.li> Hi Chris, On Sat, Jan 05, 2008 at 03:38:58PM -0500, Chris Saunders wrote: > Will there be a binary release for Windows x86_64? Unfortunately not in the near future; see this ticket for more details: http://hackage.haskell.org/trac/ghc/ticket/1884 Thanks Ian From igloo at earth.li Sun Jan 6 12:20:18 2008 From: igloo at earth.li (Ian Lynagh) Date: Sun Jan 6 12:14:04 2008 Subject: GHC 6.8.1 port on FreeBSD-amd64? In-Reply-To: <20080104205445.GA30327@petunia.outback.escape.de> References: <20080104205445.GA30327@petunia.outback.escape.de> Message-ID: <20080106172018.GA17018@matrix.chaos.earth.li> On Fri, Jan 04, 2008 at 09:54:45PM +0100, Matthias Kilian wrote: > [Note: already shortly discussed with Wilhelm] > > On Fri, Nov 23, 2007 at 12:30:06PM +0000, Wilhelm B. Kloke wrote: > > > ../../compiler/stage1/ghc-inplace -package-name unix-2.2.0.0 -hide-all-packages -i -idist/build/autogen -idist/build -i. -Idist/build -Iinclude -#include "HsUnix.h" -#include "execvpe.h" -odir dist/build -hidir dist/build -stubdir dist/build -package base-3.0.0.0 -package directory-1.0.0.0 -O -XCPP -XForeignFunctionInterface -idist/build -H32m -O0 -fasm -Rghc-timing -keep-hc-files -O -c dist/build/System/Posix/Process.hs -o dist/build/System/Posix/Process.o -ohi dist/build/System/Posix/Process.hi > > > Prologue junk?: .type s32x_ret, @function > > > s32x_ret: > > > pushl %ebp > > > movl %esp, %ebp > > I see nearly the same problem with ghc-6.8.2 on OpenBSD, using the > gcc-3.3.5 included in its base system. Presumably this also happens if you do a normal build with -fvia-C, i.e. it's not specific to building from an HC file bundle? > [1] BTW: what's the point of using -fasm with -keep-hc-files? IMHO, > it should be -fviaC -keep-hc-files. Someone let me know if I should > correct this in the wiki. GHC will act as if -fvia-C is given if -keep-hc-files is given. It would be nice to update the wiki to say -fvia-C rather than -fasm to avoid confusion, though. > ps: yes, I'm slowly trying to bring HC bootstrap back to work. It's > a must-have for the OpenBSD port. Note that there is a plan to drop the registerised via-C way of compiling GHC at some point, so this isn't going to work in the long term (unless you want to bootstrap via an unregisterised compiler). Would it not be possible to have a ghc-bin package in OpenBSD, which contains a precompiled binary that can be used to compile a ghc source package? I think Gentoo does something like that. > pps: I guess, cvs-ghc would be the more correct list for sending > patches and discussing the bootstrapping stuff, right? Yup. Thanks Ian From kili at outback.escape.de Sun Jan 6 13:01:37 2008 From: kili at outback.escape.de (Matthias Kilian) Date: Sun Jan 6 12:58:51 2008 Subject: GHC 6.8.1 port on FreeBSD-amd64? In-Reply-To: <20080106172018.GA17018@matrix.chaos.earth.li> References: <20080104205445.GA30327@petunia.outback.escape.de> <20080106172018.GA17018@matrix.chaos.earth.li> Message-ID: <20080106180137.GA8704@petunia.outback.escape.de> On Sun, Jan 06, 2008 at 05:20:18PM +0000, Ian Lynagh wrote: > > > > Prologue junk?: .type s32x_ret, @function > > > > s32x_ret: > > > > pushl %ebp > > > > movl %esp, %ebp > > > > I see nearly the same problem with ghc-6.8.2 on OpenBSD, using the > > gcc-3.3.5 included in its base system. > > Presumably this also happens if you do a normal build with -fvia-C, i.e. > it's not specific to building from an HC file bundle? That's right, it's just -fvia-C that triggers the bug. > > [1] BTW: what's the point of using -fasm with -keep-hc-files? IMHO, > > it should be -fviaC -keep-hc-files. Someone let me know if I should > > correct this in the wiki. > > GHC will act as if -fvia-C is given if -keep-hc-files is given. It > would be nice to update the wiki to say -fvia-C rather than -fasm to > avoid confusion, though. Done. > > ps: yes, I'm slowly trying to bring HC bootstrap back to work. It's > > a must-have for the OpenBSD port. > > Note that there is a plan to drop the registerised via-C way of > compiling GHC at some point, so this isn't going to work in the long > term (unless you want to bootstrap via an unregisterised compiler). I think I'll be happy with unregisterised bootstrap, too, even if the actual build of the port will take longer. > Would it not be possible to have a ghc-bin package in OpenBSD, which > contains a precompiled binary that can be used to compile a ghc source > package? I think Gentoo does something like that. AFAIK, FreeBSD does it in a similar way. However, this isn't the way we do ports for OpenBSD, so I'll work towards the unregisterised bootstrap. Ciao, Kili From igloo at earth.li Sun Jan 6 17:03:10 2008 From: igloo at earth.li (Ian Lynagh) Date: Sun Jan 6 16:56:54 2008 Subject: Haddocumentation of 6.8.1 In-Reply-To: <200711301523.04142.daniel.is.fischer@web.de> References: <200711301523.04142.daniel.is.fischer@web.de> Message-ID: <20080106220310.GA2029@matrix.chaos.earth.li> On Fri, Nov 30, 2007 at 03:23:04PM +0100, Daniel Fischer wrote: > Yesterday, doing runghc ./Setup.hs haddock in zlib.0.4.0.1, I noticed that no > Haddock docs have been built for my 6.8.1. > > Feature request: Could the README in future please contain information on how > to build library documentation properly? Good point; I've added this to README: $ echo "XMLDocWays = html" > mk/build.mk $ echo "HADDOCK_DOCS = YES" >> mk/build.mk $ sh boot $ ./configure $ make $ make install $ make install-docs Thanks Ian From catamorphism at gmail.com Sun Jan 6 19:14:43 2008 From: catamorphism at gmail.com (Tim Chevalier) Date: Sun Jan 6 19:08:28 2008 Subject: GHC Core question In-Reply-To: <404396ef0801051200m3511c04ai507720bdcf1ae386@mail.gmail.com> References: <404396ef0801051200m3511c04ai507720bdcf1ae386@mail.gmail.com> Message-ID: <4683d9370801061614o62332ce4v9f3da020747bbbd2@mail.gmail.com> On 1/5/08, Neil Mitchell wrote: > Hi > > I've compiled the Debug.Trace module to Core, but can't understand the > resulting output. The original code is: > > trace string expr = unsafePerformIO $ do > putTraceMsg string > return expr > > The core is: > > Debug.Trace.trace = > \ (@ a) -> > __letrec { > trace :: GHC.Base.String -> a -> a > [] > trace = > \ (string :: GHC.Base.String) (expr :: a) -> > GHC.Base.$ > @ (GHC.IOBase.IO a) > @ a > (GHC.IOBase.unsafePerformIO @ a) > (>> @ () @ a (Debug.Trace.putTraceMsg string) (return @ a expr)); > $dMonad :: GHC.Base.Monad GHC.IOBase.IO > [] > $dMonad = $dMonad; > return :: forall a. a -> GHC.IOBase.IO a > [] > return = GHC.Base.return @ GHC.IOBase.IO $dMonad; > $dMonad :: GHC.Base.Monad GHC.IOBase.IO > [] > $dMonad = GHC.IOBase.$f16; > >> :: forall a b. > GHC.IOBase.IO a -> GHC.IOBase.IO b -> GHC.IOBase.IO b > [] > >> = GHC.Base.>> @ GHC.IOBase.IO $dMonad; > } in trace; > > And my Haskell reformatting of that is: > > Debug.Trace.trace = let > trace string expr = unsafePerformIO $ putTraceMsg string >> return expr > $dMonad = $dMonad; > return = GHC.Base.return $dMonad; > $dMonad = GHC.IOBase.$f16; > >> = GHC.Base.>> $dMonad; > in trace > > However, that let expression has two bindings for $dMonad, one of > which looks like a black-hole. Are the semantics of __letrec different > from let in some way? > How are you printing out the Core? It looks like the unique ids are missing (you can see them if you pass the -ppr-debug flag, which can be set using the API) -- if the unique ids were being printed, you would see that the bindings for $dMonad (likely) have different uniques. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "...Losing your mind, like losing your car keys, is a real hassle." -- Andrew Solomon From brianh at metamilk.com Sun Jan 6 22:01:18 2008 From: brianh at metamilk.com (Brian Hulley) Date: Sun Jan 6 21:51:27 2008 Subject: Module system, was Re: GHC source code improvement ideas In-Reply-To: <47800480.7050808@imn.htwk-leipzig.de> References: <477D987C.2090806@gmail.com> <20080104174739.GA8322@matrix.chaos.earth.li> <477ECEC1.8000109@metamilk.com> <47800480.7050808@imn.htwk-leipzig.de> Message-ID: <478195FE.90505@metamilk.com> Johannes Waldmann wrote: > Brian Hulley wrote: > >> In the long term, Haskell needs a better module system IMHO [...] > > I agree with the symptoms that were described, but I draw a different > conclusion. > > We don't need to change the language - we need better tools (IDEs) > that operate not at the textual level, but use the annotated syntax tree, > including knowledge on fully qualified names and types. Hi Johannes, I agree that better tools would be a good thing, and could improve the programming experience considerably, but I still think that an improved module system design would be an orthogonal benefit. Best regards, Brian. From wb at arb-phys.uni-dortmund.de Mon Jan 7 02:07:29 2008 From: wb at arb-phys.uni-dortmund.de (Wilhelm B. Kloke) Date: Mon Jan 7 02:01:25 2008 Subject: GHC 6.8.1 port on FreeBSD-amd64? References: <20080104205445.GA30327@petunia.outback.escape.de> <20080106172018.GA17018@matrix.chaos.earth.li> <20080106180137.GA8704@petunia.outback.escape.de> Message-ID: Matthias Kilian schrieb: > On Sun, Jan 06, 2008 at 05:20:18PM +0000, Ian Lynagh wrote: >> > > > Prologue junk?: .type s32x_ret, @function >> > > > s32x_ret: >> > > > pushl %ebp >> > > > movl %esp, %ebp >> > >> > I see nearly the same problem with ghc-6.8.2 on OpenBSD, using the >> > gcc-3.3.5 included in its base system. >> >> Presumably this also happens if you do a normal build with -fvia-C, i.e. >> it's not specific to building from an HC file bundle? > > That's right, it's just -fvia-C that triggers the bug. This is not quite the case. I compiled even with -fvia-C without errors on FreeBSD-amd64. This bug is specific for the bootstrap with crosscompiling i386 -> amd64 vi .hc-bundle. -- Dipl.-Math. Wilhelm Bernhard Kloke Institut fuer Arbeitsphysiologie an der Universitaet Dortmund Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257 PGP: http://vestein.arb-phys.uni-dortmund.de/~wb/mypublic.key From simonpj at microsoft.com Mon Jan 7 03:50:40 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Jan 7 03:44:23 2008 Subject: GHC Core question In-Reply-To: <404396ef0801051200m3511c04ai507720bdcf1ae386@mail.gmail.com> References: <404396ef0801051200m3511c04ai507720bdcf1ae386@mail.gmail.com> Message-ID: If you use -dppr-debug GHC will show you the unique number of each identifier, and that'll show you that the two $dMonads are distinct even though they have the same print-name. CoreTidy makes the print-name unique too. Perhaps the