January 2010 - Glasgow-haskell-users

partially applied type synonyms
by Arie Peterson 05 Mar '12

05 Mar '12

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

3 2

Fw: Re: Re[2]: No more ExitException? <- documentation bug
by Volker Wysk 13 Feb '10

13 Feb '10

The following message went to Bulat Ziganshin alone. So here it is for the mailing list. Sorry. Begin forwarded message: On Wed, 27 Jan 2010 12:43:13 +0300 Bulat Ziganshin <bulat.ziganshin(a)gmail.com> wrote: > > exitWith throws the ExitCode when it is called. This leads to the > > shutdown of the program, if it isn't caught. Just like ExitException. > > > This isn't documented. > > i've googled for "exitWith throws the ExitCode" and it pointed me to > the exitWith docs: "Computation exitWith code throws ExitException code." This is the source code of exitWith: -------------------------snip----------------------------- -- --------------------------------------------------------------------------- -- exitWith -- | Computation 'exitWith' @code@ throws 'ExitException' @code@. -- Normally this terminates the program, returning @code@ to the -- program's caller. Before the program terminates, any open or -- semi-closed handles are first closed. -- -- A program that fails in any other way is treated as if it had -- called 'exitFailure'. -- A program that terminates successfully without calling 'exitWith' -- explicitly is treated as it it had called 'exitWith' 'ExitSuccess'. -- -- As an 'ExitException' is not an 'IOError', 'exitWith' bypasses -- the error handling in the 'IO' monad and cannot be intercepted by -- 'catch' from the "Prelude". However it is an 'Exception', and can -- be caught using the functions of "Control.Exception". This means -- that cleanup computations added with 'Control.Exception.bracket' -- (from "Control.Exception") are also executed properly on 'exitWith'. #ifndef __NHC__ exitWith :: ExitCode -> IO a exitWith ExitSuccess = throwIO ExitSuccess exitWith code@(ExitFailure n) | n /= 0 = throwIO code #ifdef __GLASGOW_HASKELL__ | otherwise = ioError (IOError Nothing InvalidArgument "exitWith" "ExitFailure 0" Nothing) #endif #endif /* ! __NHC__ */ -------------------------snip----------------------------- As you can see, it throws the ExitCode, not an ExitException. The documentation is faulty. Cheers, Volker -- Volker Wysk <vw(a)volker-wysk.de> -- Volker Wysk <vw(a)volker-wysk.de>

2 1

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

forgetting SCC
by Serge D. Mechveliani 06 Feb '10

06 Feb '10

I have a suggestion: is it better for GHC to report an error on the source of kind {-# "foo" #-} (entered by a typo instead of {-# SCC "foo" #-}) ? Currently, GHC makes the program under (-prof) in which, the "foo" center occurs skipped. This misleads the user: "foo is not in the profiling head, so it takes zero cost". Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

2 1

Question regarding combinator call convention
by Tyson Whitehead 01 Feb '10

01 Feb '10

I was looking through the code for 6.12.1 and am a bit confused about 11.1.3 in the runtime system documentation docs/rts/rts.tex. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.79.641&rep=rep1&ty… It says the arguments passing convention to a known combinator differs from that of the others in that it starts the arguments with R1 instead of R2 (R1 points to the associated memory data structure for non-combinators). The thing I'm confused with is I would expect this would require treating combinators special, and yet I don't see an combinator specific stuff (in either ClosureTypes.h or the generated AutoApply.cmm) to treat them special. Ive also looking at functions like plusInt and a few of my own, but, apart from internal functions like stg_app_*, I'm not finding any code using the the combinator passing convention. Am I missing something? Thanks! -Tyson

2 2

building 6.12.1 with itself
by Nicolas Martyanoff 01 Feb '10

01 Feb '10

Hi, By reading Matthias Kilian's scripts (thank you !), I successfully builded GHC 6.12.1. GHC 6.10.4 didn't build: g Lexer.x gmake[2]: g: Command not found gmake[2]: [Lexer.hs] Error 127 (ignored) RTS -K2m -RTS -agc --strict Parser.y gmake[2]: RTS: Command not found gmake[2]: *** [Parser.hs] Error 127 Failed making boot in genprimopcode: 1 gmake[1]: *** [boot] Error 1 gmake: *** [stage1] Error 1 But GHC 6.8.3 did. I then built GHC 6.12.1. The only problem was that the build process doesn't find the iconv lib when it's installed in /usr/local, so the lib/include paths have to be specified when running ./configure. I then installed Cabal 1.9 from darcs, and cabal-install, still from darcs. I used cabal to install hscolour, xmonad and xmonad-contrib, it worked perfectly. I thought it might be good to build GHC 6.12.1 with itself just to be sure it's working fine before make a dist, but I now get the following error: "/usr/local/bin/ghc" -H32m -O -package-conf libraries/bootstrapping.conf -package-name ghc-6.12.1 -hide-all-packages -i -icompiler/nativeGen -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/cprAnalysis -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/main -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage1/build -icompiler/stage1/build/autogen -Icompiler/stage1/build -Icompiler/stage1/build/autogen -Icompiler/stage1 -Icompiler/../libraries/base/cbits -Icompiler/../libraries/base/include -Icompiler/. -Icompiler/parser -Icompiler/utils -optP-include -optPcompiler/stage1/build/autogen/cabal_macros.h -package Cabal-1.9.0 -package array-0.3.0.0 -package base-4.2.0.0 -package bin-package-db-0.0.0.0 -package bytestring-0.9.1.5 -package containers-0.3.0.0 -package directory-1.0.1.0 -package filepath-1.1.0.3 -package hpc-0.5.0.4 -package old-time-1.0.0.3 -package process-1.0.1.2 -package unix-2.4.0.0 -DSTAGE=1 -Wall -fno-warn-name-shadowing -fno-warn-orphans -XCPP -XMagicHash -XUnboxedTuples -XPatternGuards -XForeignFunctionInterface -XEmptyDataDecls -XTypeSynonymInstances -XMultiParamTypeClasses -XFlexibleInstances -XRank2Types -XScopedTypeVariables -XDeriveDataTypeable -XRelaxedPolyRec -odir compiler/stage1/build -hidir compiler/stage1/build -stubdir compiler/stage1/build -hisuf hi -osuf o -hcsuf hc -c compiler/main/Packages.lhs -o compiler/stage1/build/Packages.o compiler/main/Packages.lhs:233:63: Couldn't match expected type `InstalledPackageInfo_ String' against inferred type `Cabal-1.8.0.2:Distribution.InstalledPackageInfo.InstalledPackageInfo_ m' Expected type: [InstalledPackageInfo_ String] Inferred type: [Cabal-1.8.0.2:Distribution.InstalledPackageInfo.InstalledPackageInfo_ m] In the second argument of `map', namely `conf' In the first argument of `return', namely `(map installedPackageInfoToPackageConfig conf)' gmake[1]: *** [compiler/stage1/build/Packages.o] Error 1 gmake: *** [all] Error 2 I tried to "ghc-pkg mask" Cabal-1.8.0.2, then Cabal-1.9.0, didn't change anything. Does someone know what's going on here, and what can be done to fix it ? Regards, -- Nicolas Martyanoff http://codemore.org khaelin(a)gmail.com

2 1

Language extensions - backwards compatibility
by Iain Alexander 30 Jan '10

30 Jan '10

I'm looking for a way of specifying language extensions in a way which will work in all versions of GHC from 6.4 onwards. GHC 6.4 does not support the LANGUAGE pragma. Specifying language options in the OPTIONS_GHC pragma starts to produce deprecation warnings in 6.10, and will presumably eventually fail altogether. Any sort of preprocessing at the beginning of a file appears to insert enough noise to inhibit recognition of file-header pragmas. (Cpphs doesn't appear to help here.) Attempting preprocessing inside a leading OPTIONS_GHC pragma fails because it apparently attempts to interpret the pragma *before* invoking the preprocessor. The only remaining option I can see is to have a completely separate version of the file for GHC 6.4. Have I missed anything? -- Iain Alexander ia(a)stryx.demon.co.uk

5 8

cross-compiling ghc to openbsd
by Nicolas Martyanoff 30 Jan '10

30 Jan '10

Hi, I'm trying to cross-compile GHC as follows: Host: Linux, x86_64, GHC 6.12.1 Target: OpenBSD 4.6 stable, i386 I follow the guide at: http://hackage.haskell.org/trac/ghc/wiki/Building/Porting I downloaded the last stable source tarball (ghc-6.12.1-src.tar.bz2), then ran the following commands: export AUTOCONF_VERSION=2.62 export AUTOMAKE_VERSION=1.9 cp /bin/pwd utils/ghc-pwd/ghc-pwd sh boot ./configure --enable-hc-boot --build=i386-unknown-openbsd --host=i386-unknown-openbsd --target=i386-unknown-openbsd gmake bootstrapping-files The latest fails, with the following trace: http://pastebin.ca/1770926 The following errors are quite interesting: includes/stg/Types.h:103:2: #error GHC untested on this architecture: sizeof(void *) != 4 or 8 includes/rts/Constants.h:156:2: #error unknown SIZEOF_VOID_P Does someone what's going on with this build ? Is there something I can to to help on these issues ? Regards, -- Nicolas Martyanoff http://codemore.org khaelin(a)gmail.com

4 6

Re: GHC core plugins
by José Pedro Magalhães 29 Jan '10

29 Jan '10

Hi Max, 2010/1/27 Max Bolingbroke <batterseapower(a)hotmail.com> > 2010/1/27 José Pedro Magalhães <jpm(a)cs.uu.nl>: > > Alright, ticket created: http://hackage.haskell.org/trac/ghc/ticket/3843 > > > > In any case, for now I am willing to hard-code a new core-to-core pass on > > the compiler. Any pointers for where I have to look at? > > I recommend you look at compiler/simplCore/CSE.lhs. It is a simple > example of a core-to-core pass. > > However, in short you'll need to: > 1) Create a function which implements your core to core pass, of a > type such as [CoreBind] -> [CoreBind] > *) If that function lives in a new module, edit ghc.cabal.in to tell > the build system about the module > 2) Add a constructor to the CoreToDo data type in > compiler/simplCore/CoreMonad.lhs > 3) Add a case for it to the coreDumpFlag and Outputable instance > 4) Add that pass to the list returned by getCoreToDo in CoreMonad. The > order of the list is the order the passes will be run in. > *) If you want the pass to be under the control of a new flag, you'll > need to add a new dynflag - add a constructor to the DOpt data type in > compiler/main/DynFlags.lhs, and add something to build that > constructor to one of the lists that get fed to the command line > handling code in the same module. It should be fairly obvious how to > do this. > 5) Add a handler for the new constructor to > compiler/simplCore/SimplCore.lhs, in the doCorePass function which > calls into the core pass function you wrote > > Hope that helps, > Max > Yes, that helped quite a lot. One last thing: currently it takes me about 6 minutes to rebuild the compiler after I change the core pass. Are there any tricks of the build system I can use to speed this up? I'm already using a fast build without optimizations and docs... Thanks, Pedro

3 3

bug in template haskell (with recursion?)
by Jake Wheat 28 Jan '10

28 Jan '10

Hello All, I'm trying to write a splice to make HList type signatures a bit more concise, I don't know whether this is a good idea or not. I wrote a small function to do '[(Type,Type)] -> Q Type' for this, and got the following from GHC. Should I add this to the bug tracker? Details: THBug1.hs: {-# LANGUAGE TemplateHaskell #-} module THBug1 where import Data.HList import Language.Haskell.TH mhlt :: [(Type,Type)] -> Q Type mhlt x = [t| Record $(foldThing x)|] where foldThing ((f,t):xs) = [t|HCons (LVPair (Proxy $f) $t) $(foldThing xs)|] foldThing [] = [t|HNil|] ---- $ ghc -c THBug1.hs THBug1.hs:12:61: GHC internal error: `foldThing' is not in scope during type checking, but it passed the renamer tcg_type_env of environment: [] In the expression: foldThing xs In the Template Haskell quotation [t| HCons (LVPair (Proxy $f) $t) $(foldThing xs) |] In the expression: [t| HCons (LVPair (Proxy $f) $t) $(foldThing xs) |] I'm using GHC 6.12.1 from debian experimental: $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.12.1 $ ghc-pkg list |grep template template-haskell-2.4.0.0 To get HList to install with GHC 6.12, I downloaded the latest version from http://old-darcs.well-typed.com/HList/ and altered it slightly, updated package here: http://launchpad.net/hssqlppp/prealpha/environment/+download/HList-0.2.tar.… the changes I made are: diff -rN old-HList/Data/HList/GhcSyntax.hs new-HList/Data/HList/GhcSyntax.hs 2c2 < {-# LANGUAGE FlexibleContexts #-} --- > {-# LANGUAGE FlexibleContexts, TypeOperators #-} diff -rN old-HList/Data/HList/Label2.hs new-HList/Data/HList/Label2.hs 1c1,2 < {-# LANGUAGE FlexibleInstances, MultiParamTypeClasses, UndecidableInstances, EmptyDataDecls #-} --- > {-# LANGUAGE FlexibleInstances, MultiParamTypeClasses, UndecidableInstances, EmptyDataDecls, > ExistentialQuantification #-} 36c37 < data HNat x => Label x ns desc -- labels are exclusively type-level entities --- > data Label x ns desc = HNat x => Label x ns desc -- labels are exclusively type-level entities diff -rN old-HList/Data/HList/Label3.hs new-HList/Data/HList/Label3.hs 1c1,2 < {-# LANGUAGE FlexibleInstances, MultiParamTypeClasses, UndecidableInstances, EmptyDataDecls #-} --- > {-# LANGUAGE FlexibleInstances, MultiParamTypeClasses, UndecidableInstances, EmptyDataDecls, > ExistentialQuantification #-} 37c38 < data HNat x => Label x ns desc -- labels are exclusively type-level entities --- > data Label x ns desc = HNat x => Label x ns desc -- labels are exclusively type-level entities (If it's not obvious, I have no idea what I'm doing..., but my small amount of code which uses HList worked fine with this altered package.) Thanks, Jake Wheat

1 1