November 2009 - Glasgow-haskell-users

partially applied type synonyms
by Arie Peterson 05 Mar '12

05 Mar '12

Dear list, Is there a good reason that partially applied type synonyms cannot be made instances of classes? - A simple example would be making the identity type 'Id' ("type Id x = x") instance of 'Monad'. This would eliminate the need for some silly occurrences of 'runIdentity', and perhaps narrow the gap between monads and monad transformers. - The reason I complain about this now is a more involved example, where introducing a newtype to work around the restriction is not an option. Well, not as far as I can see now, anyway. Partially applied type synonyms are, in a sense, the anonymous functions at the type level, and one might argue that they deserve the same 'first-class member status' as the lambda at the value level. Kind regards, Arie Peterson

3 2

Update on GHC 6.12.1
by Simon Peyton-Jones 09 Feb '10

09 Feb '10

Folks This is an update on the status of GHC 6.12. FIRST, as you probably know, Hackage and the Haskell Platform is allowing GHC HQ to get out of the libraries business. So the plan is - We release GHC 6.12 with very few libraries - Bill Library Author downloads GHC 6.12 and tests his libraries - The next Haskell Platform release packages GHC 6.12 with these tested libraries - Joe User downloads the Haskell Platform. - Four months later there's a new HP release, still with GHC 6.12, but with more or better libraries. The HP release cycle is decoupled from GHC So if you are Joe User, you want to wait for the HP release. Don't grab the GHC 6.12 release. It'll be perfectly usable, but only if you use (an up to date) cabal-install to download libraries, and accept that they may not be tested with GHC 6.12. SECOND, we have produced Release Candidate 1 for GHC 6.12.1, and are about to produce RC2. However, before releasing 6.12 we'd like to compile all of Hackage, in case doing so reveals bugs in GHC's APIs (which are not supposed to change). But we can't do that until an update to cabal-install is ready. (We don't expect this dependency to happen all the time, but it does hold for 6.12.) Duncan has been working on the cabal-install update, and expects to release by end November. So the timetable looks like this: - Very soon: GHC 6.12.1 release candidate 2 - End Nov: cabal-install release - ...test GHC against Hackage... - Early Dec: release GHC 6.12 - ...library authors and HP folk get busy... - End Jan (?): Haskell Platform release - ...Joe User downloads HP... FINALLY, below I summarise a late change that's been pending for a long time, which I propose to sneak into RC2, for reasons explained below. If you can see a good reason not to do this, yell. Simon Recursive do-notation. ~~~~~~~~~~~~~~~~~~~~~~ The change is this. Instead of writing mdo { a <- getChar ; b <- f c ; c <- g b ; putChar c ; return b } you would write do { a <- getChar ; rec { b <- f c ; c <- g b } ; putChar c ; return b } That is, * 'mdo' is eliminated * 'rec' is added, which groups a bunch of statements into a single recursive statement See http://hackage.haskell.org/trac/ghc/ticket/2798 This 'rec' thing is already present for the arrow notation, so it makes the two more uniform. Moreover, 'rec' lets you say more precisely where the recursion is (if you want to), whereas 'mdo' just says "there's recursion here somewhere". Lastly, all this works with rebindable syntax (which mdo does not). Currently 'mdo' is enabled by -XRecursiveDo. So we propose to deprecate this flag, with another flag -XDoRec to enable the 'rec' keyword. The main question is not whether to make this change, but when. I'm inclined to do put it into GHC 6.12, even though it's late in the day because then we can take mdo out of 6.14 altogether. Another minor question is whether "-XDoRec" is a good name for the flag. We can't really use "-XRecursiveDo" because that's the one we are deprecating!

12 18

Porting to DragonFly BSD
by Colin Adams 15 Dec '09

15 Dec '09

When GHC 6.12.1 is released, I'm going to have a go at porting it to DragonFly BSD (32-bit incarnation). Is the porting page on the wikiup-to-date? -- Colin Adams Preston, Lancashire, ENGLAND

9 19

Formal semantics for Core?
by Matthijs Kooijman 10 Dec '09

10 Dec '09

Hi All, I was wondering if there are any formal semantics defined for GHC's core language? I'm working with some core to core rewriting passes for which I'd like to verify the soundness, but that would require some formal definition of the Core semantics of sorts... Gr. Matthijs

4 4

A few small points about GHCi command documentation in section 2.7
by Yitzchak Gale 01 Dec '09

01 Dec '09

Please add to the documentation for :set prompt: If you enclose \i{prompt} in quotes, you can use Haskell syntax for String literals. Actually, :set prompt is nearly useless without quotes, because GHCi strips off trailing spaces from commands. We should either add a space at the end of a prompt entered without quotes, or just require quotes. Or at least change the help text to be: :set prompt \"<prompt>\" set the prompt used in GHCi\n so that people will know the right thing to do. Perhaps add a few more words of explanation to the docs in section 2.7 once we decide which of these to do. The :run command is not documented in section 2.7 - the only mention of it is buried within the documentation for the :main command. It is also not mentioned in helpText. Thanks, Yitz

2 1

GHC 6.12 + zlib + Mac OS 10.6
by Antoine Latter 30 Nov '09

30 Nov '09

Hello folks, Everything has been going beautifully with the latest versions of GHC 6.12, except that anything involving zlib dies at run-time. In ghci: > :m Codec.Compression.Zlib > :m +Data.ByteString.Lazy.Char8 > :s -XOverloadedStrings > compress "hello" *** Exception: user error (Codec.Compression.Zlib: incompatible zlib version) I'm running OS X 10.6 on a 64-bit machine. I've heard of folks running into this with GHC 6.10 on OS X 10.6, who got rid of it by removing mac-ports. I tried that and it didn't change anything. My mac-ports install should have all been universal binaries anyway. I imagine I'm somehow building against a 64-bit version of the zlib library, but I'm not sure at what step I'm supposed to do things different, or what precisely I'm supposed to do different. Thanks, Antoine

5 11

mysteriously hidden ghc-binary-0.5.0.2
by Donn Cave 28 Nov '09

28 Nov '09

Trying to build ghc-6.12.0.20091121, from an hc bootstrap build of ghc-6.12.0.20091010 -- i.e., first self hosted build of ghc. I'm hung up at the point where, after building ghc-cabal, ghc-pkg, hsc2hs etc., it tries to generate dependencies (?) for a Binary.hs in libraries/bin-package-db. It can't find module 'Data.Binary' - "It is a member of the hidden package `ghc-binary-0.5.0.2'." OK, I am not familiar with packages, except insofar as encountered while trying to build GHC, but from "ghc-pkg list", I would not get the impression that ghc-binary-0.5.0.2 is hidden (no parentheses.) I get this result with either ghc-pkg, from the 20091010 build where ghc-stage2 is, or the newly built 20091121 version. The command line seems to correctly have -hide-all-packages, followed eventually by -package ghc-binary-0.5.0.2. The command and results below. Is this a configuration problem with 6.12.0, or is it more likely that my ghc build is defective? Thanks! Donn Cave, donn(a)avvanta.com /boot/home/src/ghc/ghc-6.12.0.20091010/inplace/bin/ghc-stage2 -v -M -include-pkg-deps -dep-makefile libraries/bin-package-db/dist-boot/build/.depend-v -H64m -O0 -fasm -package-conf libraries/bootstrapping.conf -package-name bin-package-db-0.0.0.0 -hide-all-packages -i -ilibraries/bin-package-db/. -ilibraries/bin-package-db/dist-boot/build -ilibraries/bin-package-db/dist-boot/build/autogen -Ilibraries/bin-package-db/dist-boot/build -Ilibraries/bin-package-db/dist-boot/build/autogen -Ilibraries/bin-package-db/. -optP-include -optPlibraries/bin-package-db/dist-boot/build/autogen/cabal_macros.h -package Cabal-1.8.0.1 -package base-4.2.0.0 -package ghc-binary-0.5.0.2 -fno-warn-deprecated-flags -odir libraries/bin-package-db/dist-boot/build -hidir libraries/bin-package-db/dist-boot/build -stubdir libraries/bin-package-db/dist-boot/build -hisuf hi -osuf o -hcsuf hc libraries/bin-package-db/./Distribution/InstalledPackageInfo/Binary.hs Glasgow Haskell Compiler, Version 6.12.0.20091010, for Haskell 98, stage 2 booted by GHC version 6.8.3 Using binary package database: /boot/home/src/ghc/ghc-6.12.0.20091010/inplace/lib/package.conf.d/package.cache Using package config file: libraries/bootstrapping.conf wired-in package ghc-prim mapped to ghc-prim-0.2.0.0-inplace wired-in package integer-gmp mapped to integer-gmp-0.2.0.0-inplace wired-in package base mapped to base-4.2.0.0-inplace wired-in package rts mapped to builtin_rts wired-in package haskell98 mapped to haskell98-1.0.1.1-inplace wired-in package template-haskell mapped to template-haskell-2.4.0.0-inplace wired-in package dph-seq mapped to dph-seq-0.4.0-inplace wired-in package dph-par mapped to dph-par-0.4.0-inplace Hsc static flags: -funregisterised -static Created temporary directory: /tmp/ghc47745_0 *** Chasing dependencies: Chasing modules from: *libraries/bin-package-db/Distribution/InstalledPackageInfo/Binary.hs libraries/bin-package-db/Distribution/InstalledPackageInfo/Binary.hs:21:7: Could not find module `Data.Binary': It is a member of the hidden package `ghc-binary-0.5.0.2'. locations searched: libraries/bin-package-db/./Data/Binary.hs libraries/bin-package-db/./Data/Binary.lhs libraries/bin-package-db/dist-boot/build/Data/Binary.hs libraries/bin-package-db/dist-boot/build/Data/Binary.lhs libraries/bin-package-db/dist-boot/build/autogen/Data/Binary.hs libraries/bin-package-db/dist-boot/build/autogen/Data/Binary.lhs *** Deleting temp files: Deleting: /tmp/ghc47745_0/ghc47745_0.dep *** Deleting temp dirs: Deleting: /tmp/ghc47745_0

1 0

Build of HEAD fails in integer-gmp
by Bryan O'Sullivan 27 Nov '09

27 Nov '09

I get this error message, which suggests that the gmp-wrappers file should be compiled with -fPIC but isn't being: /usr/bin/ld: libraries/integer-gmp/dist-install/build/cbits/gmp-wrappers.dyn_o: relocation R_X86_64_PC32 against undefined symbol `__gmpz_init' can not be used when making a shared object; recompile with -fPIC

2 2

Build ghc with hardened toolchain
by 章宏九 27 Nov '09

27 Nov '09

Hello. I am using Gentoo with hardened features enabled. Recently i want to try yi-editor. I built GHC with emerge and nothing strange happened. However, I got following error information when i built yi: Building yi-0.6.1... [ 1 of 119] Compiling System.FriendlyPath ( System/FriendlyPath.hs, dist/build/System/FriendlyPath.o ) [ 2 of 119] Compiling Shim.ProjectContent ( Shim/ProjectContent.hs, dist/build/Shim/ProjectContent.o ) [ 3 of 119] Compiling Parser.Incremental ( Parser/Incremental.hs, dist/build/Parser/Incremental.o ) [ 4 of 119] Compiling Data.Trie ( Data/Trie.hs, dist/build/Data/Trie.o ) [ 5 of 119] Compiling Data.DelayList ( Data/DelayList.hs, dist/build/Data/DelayList.o ) [ 6 of 119] Compiling Data.Rope ( Data/Rope.hs, dist/build/Data/Rope.o ) [ 7 of 119] Compiling Data.Prototype ( Data/Prototype.hs, dist/build/Data/Prototype.o ) [ 8 of 119] Compiling HConf.Utils ( HConf/Utils.hs, dist/build/HConf/Utils.o ) [ 9 of 119] Compiling HConf.Paths ( HConf/Paths.hs, dist/build/HConf/Paths.o ) [ 10 of 119] Compiling Paths_yi ( dist/build/autogen/Paths_yi.hs, dist/build/Paths_yi.o ) [ 11 of 119] Compiling HConf ( HConf.hs, dist/build/HConf.o ) [ 12 of 119] Compiling Yi.Char.Unicode ( Yi/Char/Unicode.hs, dist/build/Yi/Char/Unicode.o ) [ 13 of 119] Compiling Yi.UI.Common[boot] ( Yi/UI/Common.hs-boot, dist/build/Yi/UI/Common.o-boot ) [ 14 of 119] Compiling Yi.String ( Yi/String.hs, dist/build/Yi/String.o ) [ 15 of 119] Compiling Yi.Monad ( Yi/Monad.hs, dist/build/Yi/Monad.o ) [ 16 of 119] Compiling Yi.Keymap.Completion ( Yi/Keymap/Completion.hs, dist/build/Yi/Keymap/Completion.o ) [ 17 of 119] Compiling Yi.Editor[boot] ( Yi/Editor.hs-boot, dist/build/Yi/Editor.o-boot ) [ 18 of 119] Compiling Yi.Debug ( Yi/Debug.hs, dist/build/Yi/Debug.o ) [ 19 of 119] Compiling Yi.Prelude ( Yi/Prelude.hs, dist/build/Yi/Prelude.o ) [ 20 of 119] Compiling Yi.Dynamic ( Yi/Dynamic.hs, dist/build/Yi/Dynamic.o ) [ 21 of 119] Compiling Yi.Event ( Yi/Event.hs, dist/build/Yi/Event.o ) [ 22 of 119] Compiling Yi.Interact ( Yi/Interact.hs, dist/build/Yi/Interact.o ) [ 23 of 119] Compiling Yi.Keymap[boot] ( Yi/Keymap.hs-boot, dist/build/Yi/Keymap.o-boot ) [ 24 of 119] Compiling Yi.Style ( Yi/Style.hs, dist/build/Yi/Style.o ) [ 25 of 119] Compiling Yi.Style.Library ( Yi/Style/Library.hs, dist/build/Yi/Style/Library.o ) [ 26 of 119] Compiling Yi.Interpreter ( Yi/Interpreter.hs, dist/build/Yi/Interpreter.o ) [ 27 of 119] Compiling Shim.Utils ( Shim/Utils.hs, dist/build/Shim/Utils.o ) [ 28 of 119] Compiling Shim.CabalInfo ( Shim/CabalInfo.hs, dist/build/Shim/CabalInfo.o ) [ 29 of 119] Compiling Yi.Buffer.Misc[boot] ( Yi/Buffer/Misc.hs-boot, dist/build/Yi/Buffer/Misc.o-boot ) [ 30 of 119] Compiling Yi.Buffer.Basic ( Yi/Buffer/Basic.hs, dist/build/Yi/Buffer/Basic.o ) ghc: /usr/lib/ghc-6.10.4/ghc-prim-0.1.0.0/HSghc-prim-0.1.0.0.o: unknown symbol `_GLOBAL_OFFSET_TABLE_' Loading package ghc-prim ... linking ... ghc: unable to load package `ghc-prim' I notice that Gentoo has already done some works about disabling hardened features temporarily for Haskell. Here is the mk/build.mk: # Gentoo changes docdir = /usr/share/doc/ghc-6.10.4 htmldir = /usr/share/doc/ghc-6.10.4 SRC_HC_OPTS+= -optc-march=native -opta-march=native -optc-nopie -optl-nopie -optc-fno-PIE -opta-Wa,--noexecstack SRC_CC_OPTS+=-O2 -march=native -pipe -nopie -Wa,--noexecstack XMLDocWays= HADDOCK_DOCS=NO SRC_HC_OPTS+=-w While talking on IRC (#gentoo-haskell and #haskell) I was told that this might be caused by a broken GHC. Although above shows that PIE are disabled, ghc-prim (maybe at least) is still built with PIE enabled. According to advice from #gentoo-haskell, I was told to seek for help here. I also submit a bug about it as #3668. (Very sorry that I ask everywhere. Forgive me, but until yesterday I forgot my password of my gmail and cannot join a mailling-list.) Thank igloo told me add "-nopie" in SRC_LD_OPTS. I did but still failed: ------------------------------------------------------------------------ == make boot - --no-print-directory -r --jobserver-fds=3,4 - --jobserver-fds=3,4 -j; in /var/tmp/portage/dev-lang/ghc-6.10.4/work/ghc-6.10.4/utils/genapply ------------------------------------------------------------------------ /var/tmp/portage/dev-lang/ghc-6.10.4/work/usr/bin/ghc -package-conf /var/tmp/portage/dev-lang/ghc-6.10.4/work/ghc-6.10.4/libraries/bootstrapping.conf -H32m -O -optc-march=native -opta-march=native -optc-nopie -optl-nopie -opta-Wa,--noexecstack -w -package pretty -fforce-recomp -c GenApply.hs -o GenApply.o -ohi GenApply.hi /var/tmp/portage/dev-lang/ghc-6.10.4/work/usr/bin/ghc -M -dep-makefile .depend -osuf o -package-conf /var/tmp/portage/dev-lang/ghc-6.10.4/work/ghc-6.10.4/libraries/bootstrapping.conf -package-conf /var/tmp/portage/dev-lang/ghc-6.10.4/work/ghc-6.10.4/libraries/bootstrapping.conf -H32m -O -optc-march=native -opta-march=native -optc-nopie -optl-nopie -opta-Wa,--noexecstack -w -package pretty -fforce-recomp GenApply.hs /var/tmp/portage/dev-lang/ghc-6.10.4/work/usr/bin/ghc -o genapply -package-conf /var/tmp/portage/dev-lang/ghc-6.10.4/work/ghc-6.10.4/libraries/bootstrapping.conf -H32m -O -optc-march=native -opta-march=native -optc-nopie -optl-nopie -opta-Wa,--noexecstack -w -package pretty -fforce-recomp -nopie GenApply.o ghc: unrecognised flags: -nopie Usage: For basic information, try the `--help' option. make[2]: *** [genapply] Error 1 Failed making boot in genapply: 1 make[1]: *** [boot] Error 1 make: *** [stage1] Error 1 I am surprised that why "-nopie" is sent here. Since wiki only told me to see config.mk.in and it does not have any examples, I have no idea about SRC_LD_OPTS. I need help how to completely disable PIE for GHC. Thank you very much. Hongjiu Zhang

1 2

conservative optimizations
by Alexei Kitaev 27 Nov '09

27 Nov '09

Dear GHC team, I have observed a space leak in a simple program compiled with -O option. The problem is to compute the "Fibonacci rabbit sequence": [1,0,1,1,0,1,0,1,1,0,1,1,0,...] see e.g., this Haskell Cafe discussion: http://www.haskell.org/pipermail/haskell-cafe/2007-November/034236.html I like this problem because I studied the spectrum of the Schrodinger operator defined by this sequence a while ago. Anyway, here are two slightly different programs that compute the rabbit sequence: -- Version 1: O(n) time, O(n) space rs :: [Int] rs = 1: tail [x | r <- rs, x <- f r] where f 0 = [1] f 1 = [1,0] main :: IO () main = print $ take 100 rs -- Version 2: O(n) time, O(log n) space rs :: () -> [Int] rs () = 1: tail [x | r <- rs(), x <- f r] where f 0 = [1] f 1 = [1,0] -- test of memory usage main :: IO () main = print $ rs() !! (10^8) When the second program is compiled with -O flag (using GHC-6.10.4 or the latest version, 6.13.20091125), it eats up a lot of memory. After some web searching and experimentation, I found that the space leak can be fixed by compiling with -fno-full-laziness and inserting {-# NOINLINE rs #-} However, I still have a few of questions: 1) Why would inlining introduce a space leak? This looks like a compiler bug to me. 2) Is there a set of "safe" or, if this is a better word, "conservative" optimizations that never increase the running time or space usage more than by a constant factor? This leads to another question: relative to what? I understand that prescribing the exact evaluation order and other details would be impractical, but is it possible to define *some* aspects of the program behavior that would allow the programmer to guarantee the correct asymptotic efficiency? Thank you, Alexei Kitaev

1 0