- Glasgow-haskell-users

extra libraries vs. cabal libraries (ghc-6.10.1)
by Christian Maeder 16 Nov '08

16 Nov '08

Hi, the documentation of extra libraries is listed under share/doc/ghc/libraries/ 1. Is it possible to add cabal packages in the same way? How? 2. It would be nice if the cabal-install (i.e. the binary cabal) came with ghc. Currently zlib, HTTP and cabal-install have to be (awkwardly) installed via Setup before being able to "cabal install". Cheers Christian

3 2

editline in ghc-6.10.1 under Solaris
by Christian Maeder 16 Nov '08

16 Nov '08

Hallo Judah, I've build http://www.thrysoee.dk/editline/libedit-20080712-2.11.tar.gz and it was linked against libcurses: -bash-3.1$ ldd /usr/local/lib/libedit.so.0 libcurses.so.1 => /lib/libcurses.so.1 libc.so.1 => /lib/libc.so.1 libgcc_s.so.1 => /usr/local/lang/lib/gcc/i386-pc-solaris2.10/4.2.2/libgcc_s.so.1 libm.so.2 => /lib/libm.so.2 When building ghc-6.10.1 your configure script prefers ncurses over curses, therefore I get an additional dependency for ghc: libncurses.so.5 => /usr/local/lib/libncurses.so.5 For (the usual) dynamic linking just "-ledit" is enough, only for static linking "-lcurses" or "-lncurses" is needed, otherwise "term.o" is the "Undefined symbol". (By chance, I've only libncurses.a and no libcurses.a for static linking.) I'm not sure which dependency to prefer. configure of libedit-20080712-2.1 prefers curses over ncurses. Cheers Christian P.S. While relinking the stage2 compiler I'll noticed that also haddock depends on libedit which I think should be avoided (by splitting the ghc package)! Which other ghc-6.10.1 binaries depend on libedit? P.P.S My PC binary distribution is here: http://www.dfki.de/sks/hets/pc-solaris/ghcs/ghc-6.10.1-i386-unknown-solaris… I did not succeed to build ghc-6.10.1 for a Sparc http://hackage.haskell.org/trac/ghc/ticket/2692

2 1

RPM for 6.10.1 on Fedora?
by Colin Paul Adams 16 Nov '08

16 Nov '08

I have 6.8.2 installed here (Fedora 9 x86_64). Doing a yum update says no update available. Does this mean I have yum wrongly configured, or is it just the case that the 6.10.1 roms haven't been built yet? -- Colin Adams Preston Lancashire

1 0

Re: "A lazy (~) pattern cannot bind existential type variables"?
by Conal Elliott 16 Nov '08

16 Nov '08

> > > data HasShow = forall a. Show a => HasShow a > > weird ~(HasShow x) = HasShow x > > Now, what Show context is referred to by the result of "weird undefined"? > I'd expect bottom, just as with matching ~(x,y) against bottom. The lambda is not the same as the "where" clause. Let's desugar a few > of the code snippets you gave me: [...] > Thanks. I get it now, and I see that the only version that makes it through the type-checker is the one that defeats laziness and therefore generally breaks these nice morphism properties. That algebraic failure seems reason enough to try fixing ghc. - Conal On Sun, Nov 16, 2008 at 2:18 AM, Ryan Ingram <ryani.spam(a)gmail.com> wrote: > > My brain just exploded. > > Best compiler error message ever. > > I think that existential quantification with lazy matches can do some > crazy things to the type system. > > > lazyPair ~(a,b) = (a,b). > > So, lazyPair undefined = (undefined, undefined); it makes any pair > "more defined". But what does this do when you have an existential > context? > > > data HasShow = forall a. Show a => HasShow a > > weird ~(HasShow x) = HasShow x > > Now, what Show context is referred to by the result of "weird undefined"? > > > useShow (HasShow x) = show x > > broken = useShow (weird undefined) > > It's likely that there is a way to solve this; you need to force the > pattern match to take place anywhere that the existential type gets > applied (in the System F sense). But I think that doing so is a lot > more difficult for the compiler author, and it's an edge case in the > language. > > The lambda is not the same as the "where" clause. Let's desugar a few > of the code snippets you gave me: > > > fmap g ~(WC f k) = WC f (fmap g k) > => fmap = \g wc -> let (WC f k) = wc in WC f (fmap g k) > > > fmap g wc = WC f (fmap g k) > > where WC f k = wc > => fmap = \g wc -> let (WC f k) = wc in WC f (fmap g k) > (same as above) > > > fmap g = \ (WC f k) -> WC f (fmap g k) > => fmap = \g wc -> case wc of (WC f k) -> WC f (fmap g k) > (i.e. the same as not using a lazy pattern at all) > > I'll think about this and see if I can come up with a workaround. I'm > not sure it's possible in GHC. > > -- ryan > > > On Sat, Nov 15, 2008 at 10:33 PM, Conal Elliott <conal(a)conal.net> wrote: > > What is the reasoning behind the ghc restriction that "A lazy (~) pattern > > cannot bind existential type variables"? > > > > This error came up for me in the following code: > > > > -- | Add a continuation. > > data WithCont h b c = forall a. WC (h b a) (a -> c) > > > > instance Functor (WithCont h b) where > > fmap g ~(WC f k) = WC f (fmap g k) > > > > The error message: > > > > A lazy (~) pattern cannot bind existential type variables > > `a' is a rigid type variable bound by > > the constructor `WC' at Data/Zip/FoldL.hs:66:11 > > In the pattern: ~(WC f k) > > > > I also tried this variation: > > > > instance Functor (WithCont h b) where > > fmap g wc = WC f (fmap g k) > > where WC f k = wc > > > > and got this message: > > > > My brain just exploded. > > I can't handle pattern bindings for existentially-quantified > > constructors. > > Instead, use a case-expression, or do-notation, to unpack the > > constructor. > > In the binding group for > > WC f k > > In a pattern binding: WC f k = wc > > > > I can work around these limitations by using a lambda: > > > > instance Functor (WithCont h b) where > > fmap g = \ (WC f k) -> WC f (fmap g k) > > > > which I believe is equivalent. Please correct me if I'm wrong here. > > > > For infix definitions like (<*>), however, this work-around is less > > pleasant. > > For instance, > > > > (<*>) = \ (WC hf hk) (WC xf xk) -> > > WC (hf `zip` xf) (\ (a,a') -> (hk a) (xk a')) > > > > instead of the prettier but forbidden > > > > ~(WC hf hk) <*> ~(WC xf xk) = > > WC (hf `zip` xf) (\ (a,a') -> (hk a) (xk a')) > > > > > > If you're curious what these definitions are about, see > > http://conal.net/blog/posts/enhancing-a-zip/ . > > > > Thanks, - Conal > > > > >

1 0

GHC on powerpc (OS X): segmentation fault
by Chris Kuklewicz 16 Nov '08

16 Nov '08

I am having trouble compiling GHC using mac ports on powerpc OS X (10.5.5) (using XCode 3.1). I have also opened a ticket at http://trac.macports.org/ticket/17184 which has the full build log attached. The build starts with > nice port -c upgrade ghc > ---> Staging gmp into destroot > ---> Packaging tgz archive for gmp 4.2.4_0 > ---> Deactivating gmp 4.2.3_0 > ---> Installing gmp 4.2.4_0 > ---> Activating gmp 4.2.4_0 > ---> Cleaning gmp > ---> Fetching ghc > ---> Attempting to fetch ghc-6.10.1-src.tar.bz2 from http://haskell.org/ghc/dist/stable/dist/ > ---> Attempting to fetch ghc-6.10.1-src-extralibs.tar.bz2 from http://haskell.org/ghc/dist/stable/dist/ > ---> Attempting to fetch ghc-6.8.2-darwin-ppc-leopard-bootstrap.tar.bz2 from http://haskell.org/ghc/dist/6.8.2/ > ---> Verifying checksum(s) for ghc > ---> Extracting ghc > ---> Applying patches to ghc > ---> Configuring ghc > ---> Building ghc with target all > Error: Target org.macports.build returned: shell command "cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.1 && env DYLD_FALLBACK_LIBRARY_PATH=/opt/local/lib make" returned error 2 > Command output: /private/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.1/ghc/stage1-inplace/ghc -optc-O -optc-I/opt/local/include -optc-Wall -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-I../includes -optc-I. -optc-Iparallel -optc-Ism -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -optc-I/opt/local/include -optc-I../gmp/gmpbuild -optc-I../libffi/build/include -optc-fno-strict-aliasing -H32m -O -I/opt/local/include -L/opt/local/lib -optc-O2 -I../includes -I. -Iparallel -Ism -DCOMPILING_RTS -package-name rts -static -I/opt/local/include -I../gmp/gmpbuild -I../libffi/build/include -I. -dcmm-lint -c parallel/GranSim.c -o parallel/GranSim.o Eventually the build fails with > /private/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.1/ghc/stage1-inplace/ghc -optc-O -optc-I/opt/local/include -optc-Wall -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-I../includes -optc-I. -optc-Iparallel -optc-Ism -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -optc-I/opt/local/include -optc-I../gmp/gmpbuild -optc-I../libffi/build/include -optc-fno-strict-aliasing -H32m -O -I/opt/local/include -L/opt/local/lib -optc-O2 -I../includes -I. -Iparallel -Ism -DCOMPILING_RTS -package-name rts -static -I/opt/local/include -I../gmp/gmpbuild -I../libffi/build/include -I. -dcmm-lint -c sm/Sweep.c -o sm/Sweep.o > /private/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.1/ghc/stage1-inplace/ghc -H32m -O -I/opt/local/include -L/opt/local/lib -optc-O2 -I../includes -I. -Iparallel -Ism -DCOMPILING_RTS -package-name rts -static -I/opt/local/include -I../gmp/gmpbuild -I../libffi/build/include -I. -dcmm-lint -c Apply.cmm -o Apply.o > make[1]: *** [Apply.o] Segmentation fault > make: *** [stage1] Error 2 Does anyone have a clue how to proceed?

5 9

"A lazy (~) pattern cannot bind existential type variables"?
by Conal Elliott 16 Nov '08

16 Nov '08

What is the reasoning behind the ghc restriction that "A lazy (~) pattern cannot bind existential type variables"? This error came up for me in the following code: -- | Add a continuation. data WithCont h b c = forall a. WC (h b a) (a -> c) instance Functor (WithCont h b) where fmap g ~(WC f k) = WC f (fmap g k) The error message: A lazy (~) pattern cannot bind existential type variables `a' is a rigid type variable bound by the constructor `WC' at Data/Zip/FoldL.hs:66:11 In the pattern: ~(WC f k) I also tried this variation: instance Functor (WithCont h b) where fmap g wc = WC f (fmap g k) where WC f k = wc and got this message: My brain just exploded. I can't handle pattern bindings for existentially-quantified constructors. Instead, use a case-expression, or do-notation, to unpack the constructor. In the binding group for WC f k In a pattern binding: WC f k = wc I can work around these limitations by using a lambda: instance Functor (WithCont h b) where fmap g = \ (WC f k) -> WC f (fmap g k) which I believe is equivalent. Please correct me if I'm wrong here. For infix definitions like (<*>), however, this work-around is less pleasant. For instance, (<*>) = \ (WC hf hk) (WC xf xk) -> WC (hf `zip` xf) (\ (a,a') -> (hk a) (xk a')) instead of the prettier but forbidden ~(WC hf hk) <*> ~(WC xf xk) = WC (hf `zip` xf) (\ (a,a') -> (hk a) (xk a')) If you're curious what these definitions are about, see http://conal.net/blog/posts/enhancing-a-zip/ . Thanks, - Conal

1 0

Re: Bug in GHC6.10.1?
by José Pedro Correia 14 Nov '08

14 Nov '08

Hello I was wondering if there is a bug in GHC 6.10.1 regarding number precision. As an example, in GHCi with: > 3.0 * 0.2 I get: 0.6000000000000001 Although: > 2.0 * 0.2 0.4 I have GHC 6.10.1 on Mac OS X 10.5. Is this a known bug or should I report it? Best regards Zé Pedro

4 3

libedit.so.0
by James Swaine 14 Nov '08

14 Nov '08

I can't seem to get the latest source bundle to build (running on Red Hat). I run the configure script, then make on the source tree root, and ghc gives an error to the effect of 'could not load shared object file or library libedit.so.0'. I don't have root permissions on this machine so I can't install editline on this machine, but I downloaded the source, built in my local directory, then tried: -Setting the LD_LIBRARY_PATH environment variable to include the directory path to the libedit.so.0 library I just built. -Hand editing the makefile in ghc's 'libraries' directory to add an -L[librarydir] flag to the ghc invocation that was failing. Neither of these things worked - is there an easy way to tell the configure script that it needs to probe additional directories for these shared libraries? Thanks all! -James Swaine

3 7

Re: Notes on building 6.10.1
by Duncan Coutts 13 Nov '08

13 Nov '08

On Wed, 2008-11-12 at 12:39 -0500, Gregory Wright wrote: > Should cabal produce and error or a warning if hsc2hs is not found in > the same directory as the compiler? I suggest an error by default, > but not if --with-hsc2hs is given explicitly. I don't think so. In principle hsc2hs is not tied to ghc, it just happens to be shipped with it. The versions do not need to match up (much). It's in the same category as other pre-processors like c2hs. For the ghc build system, either it really does need an external hsc2hs in which case it should detect it in the top level configure script or it can use the one it ships with in which case it should be using the --with-hsc2hs flag. Duncan

1 0

Notes on building 6.10.1
by Gregory Wright 13 Nov '08

13 Nov '08

Hi, When building 6.10.1 under Macports, I noticed that hpc now requires that hsc2hs be present on the system (it does not use the hsc2hs built in place with the new ghc). Previous versions did not require hsc2hs to be present; the compiler could be bootstrapped from just the ghc compiler and ghc-pkg. The hpc library is the only one that requires the external hsc2hs. Is this new dependency intentional, or is this a build system bug? This problem escaped detection initially because cabal will use any hsc2hs on the path even if the --with-compiler flag is set. (--with-compiler forces a particular compiler and packaging program, but not hsc2hs.) This is just asking for trouble. For the moment, it's fixed in the Macports build by hacking hpc's Makefile to specify --with-hsc2hs. Should cabal produce and error or a warning if hsc2hs is not found in the same directory as the compiler? I suggest an error by default, but not if --with- hsc2hs is given explicitly. Best Wishes, Greg

2 2