- Glasgow-haskell-users

Attempted install on Mac OS X - recent versions - FAIL
by Phil Dennis 29 Jul '09

29 Jul '09

I am looking for some assistance with installing GHC on Mac OS X. If there is a more appropriate place for me to ask, please let me know. I have tried, with no luck so far, the 2 different binary distributions of 6.10.4 provided for the Mac on the haskell.org ghc download page (http://www.haskell.org/ghc/download_ghc_6_10_4.html#macosxintel) I have OS X version 10.5.7 with XCode version 3.1.2 installed. When I run the installer (GHC-6.10.4-i386.pkg) I get as far as the "Installation Type" screen with the following text displayed: "Click Install to perform a standard installation of this software for all users of this computer". However the 'Install' button is greyed out and cannot be clicked. The last entries in the installer log are as follows: Jul 29 00:03:29 phil-denniss-macbook-pro Installer[11740]: Glasgow Haskell Compiler Installation Log Jul 29 00:03:29 phil-denniss-macbook-pro Installer[11740]: Opened from: /Users/pjdennis/Downloads/GHC-6.10.4-i386.pkg Jul 29 00:03:30 phil-denniss-macbook-pro installdb[11743]: started (uid 96) Jul 29 00:03:30 phil-denniss-macbook-pro installdb[11743]: Opened receipt database on '/' with schema 17. Jul 29 00:03:36 phil-denniss-macbook-pro installdb[11743]: done. (0.003u + 0.003s) ALSO I tried the binary distribution (ghc-6.10.4-i386-apple-darwin.tar.bz2) which I extracted, and then ran ./configure, as instructed in the INSTALL file. After adding /Developer/usr/bin to the path (so that the configure script could find the 'ar' program) I now get the following error from the configure script: configure: error: C compiler cannot create executables See `config.log' for more details. I have pasted some of what looks relevant from config.log, below. Any help with either one of the install methods for OS X would be much appreciated. I am keen to get started trying out Haskell, instead of mucking with installers. Regards, Phil Dennis --------------------------------------------------------------- >From config.log configure:2298: found /Developer/usr/bin/gcc configure:2309: result: gcc configure:2547: checking for C compiler version configure:2554: gcc --version >&5 i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5490) Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. configure:2557: $? = 0 configure:2564: gcc -v >&5 Using built-in specs. Target: i686-apple-darwin9 Configured with: /var/tmp/gcc/gcc-5490~1/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c+ +/4.0.0 --with-slibdir=/usr/lib --build=i686-apple-darwin9 --with-arch=apple --with-tune=generic --host=i686-apple-darwin9 --target=i686-apple-darwin9 Thread model: posix gcc version 4.0.1 (Apple Inc. build 5490) configure:2567: $? = 0 configure:2574: gcc -V >&5 gcc-4.0: argument to `-V' is missing configure:2577: $? = 1 configure:2600: checking for C compiler default output file name configure:2627: gcc conftest.c >&5 ld: library not found for -lcrt1.10.5.o collect2: ld returned 1 exit status configure:2630: $? = 1 configure:2668: result: configure: failed program was: | /* confdefs.h. */ | #define PACKAGE_NAME "" | #define PACKAGE_TARNAME "" | #define PACKAGE_VERSION "" | #define PACKAGE_STRING "" | #define PACKAGE_BUGREPORT "" | /* end confdefs.h. */ | | int | main () | { | | ; | return 0; | } configure:2675: error: C compiler cannot create executables See `config.log' for more details.

1 1

ANNOUNCE: GHC version 6.10.4
by Ian Lynagh 28 Jul '09

28 Jul '09

============================================================== The (Interactive) Glasgow Haskell Compiler -- version 6.10.4 ============================================================== The GHC Team is pleased to announce a new patchlevel release of GHC. This release contains a number of bugfixes relative to 6.10.3, so we recommend upgrading. Release notes are here: http://haskell.org/ghc/docs/6.10.4/html/users_guide/release-6-10-4.html How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language; the current language version is Haskell 98, agreed in December 1998 and revised December 2002. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://hackage.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: http://hackage.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://hackage.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://hackage.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Some GHC developers hang out on #haskell on IRC, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug

6 26

[reiner.pope@gmail.com: [Haskell-cafe] SpecConstr difficulties]
by Don Stewart 28 Jul '09

28 Jul '09

Something for SimonPJ ----- Forwarded message from Reiner Pope <reiner.pope(a)gmail.com> ----- Date: Mon, 20 Jul 2009 22:09:09 +0930 From: Reiner Pope <reiner.pope(a)gmail.com> To: Haskell Cafe mailing list <haskell-cafe(a)haskell.org> Subject: [Haskell-cafe] SpecConstr difficulties Hi everyone, I've been having some trouble getting SpecConstr to work as I want it to. The following example (see end of email) came up in some code I was playing around with. The loops g1 and g2 both compute the same thing: the maximum element of the "list" (which has been fused away) of numbers from 1 to 10. Since 'maximum' is a foldl1 not a foldl, I use a strict Maybe type as an accumulator. The Maybe gets filled after the first element is seen, so the Maybe is a Just for almost the entire running of the loop. It would be good to have this recognised by SpecConstr, to create an optimised loop for the Just case. This does indeed happen for g1, but not for g2. My difficulty is that I am only able to produce code similar to g2, i.e. where the pattern matching is in a separate function, 'expose', because the 'expose' function is implemented in a type-class, like in stream-fusion. Is there some way to keep the SpecConstr while leaving the 'expose' as a separate function? Here is the code: > {-# LANGUAGE BangPatterns #-} > > module Test(ans1,ans2) where > > import Prelude hiding(Maybe(..)) > > data Maybe a = Just !a | Nothing > > Nothing `mapp` Just b = Just b > Just a `mapp` Just b = Just (max a b) > > ans1 = g1 Nothing (0::Int) > > g1 m !n = case m of > Nothing -> if n > 10 then m else g1 (m `mapp` Just n) (n+1) > Just x -> if n > 10 then m else g1 (m `mapp` Just n) (n+1) > > ans2 = g2 Nothing (0::Int) > > g2 m !n = expose m (if n > 10 then m else g2 (m `mapp` Just n) (n+1)) > expose Nothing b = b > expose (Just a) b = a `seq` b On a similar note, when I was having difficulties with this problem, I started to wonder if it would be possible to come up with a more direct way to tell GHC, "do SpecConstr on this variable". From reading the source code of the stream-fusion package, it seems that the current way of doing this is with 'expose' functions like I wrote below. Could we instead have a {-# SPECCONSTR #-} pragma, to be used on function arguments, like: foo {-# SPECCONSTR #-} x y {-# SPECCONSTR #-} z = ... This pragma should say to the GHC something like "ignore conditions H2, H5 and H6 of the SpecConstr paper, for this function and this argument". Cheers, Reiner _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ----- End forwarded message -----

3 2

can we bootstrap GHC 6.x?
by Shu Wu 26 Jul '09

26 Jul '09

Hi buddies. I've been looking for methods to bootstrap GHC 6.10 but with no luck. It seems GHC 5.0 is the last version that provides HC source for bootstrapping. I think, however, bootstrapping GHC above 6.x is still necessary. First, it will be easier to build GHC on a new platform, eg, OpenSolaris. By now I succeed building GHC 6.10.4 on OpenSolaris(x86), with the help of GHC 6.6 binary package for Solaris x86 by Christian Maeder. But that was a terrible procedure. I have to deal with bins and libs for two versions of GHC. Second, compiling GHC from strap is the only way to go into OpenSolaris' official package repository, since all packages for OpenSolaris are built by Source Juicer (http://jucr.opensolaris.org/home/) from pure source code, and there can't be any pre-installed GHC on Source Juicer Build Grid. Cheers, Wu Shu

3 2

Failed to bootstrap 6.10.4 with itself on Windows (MinGW)
by leledumbo 24 Jul '09

24 Jul '09

I've just installed 6.10.4 and try to rebuild a minimal version from source, but the rebuild process failed. It stops with message: Capability.c: error converting to pointer type on stage1. configure command: ./configure --prefix=/c/ghc CFLAGS=-O4 LDFLAGS=-s -- View this message in context: http://www.nabble.com/Failed-to-bootstrap-6.10.4-with-itself-on-Windows-%28… Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

2 6

Proposal: Deprecate ExistentialQuantification
by Niklas Broberg 24 Jul '09

24 Jul '09

Hi all, Following the discussion on the use of 'forall' and extensions that use it [1], I would hereby like to propose that the ExistentialQuantification extension is deprecated. My rationale is as follows. With the introduction of GADTs, we now have two ways to write datatype declarations, the old simple way and the GADTs way. The GADTs way fits better syntactically with Haskell's other syntactic constructs, in all ways. The general style is (somewhat simplified) "keyword type 'where' decls", where keyword can in Haskell 98 be class or instance, but with GADTs also data. The old simple way of defining data types is the odd one out. It certainly has its uses though, in particular when defining some simple (but possibly large) enum-like datatype (like cabal's Extension type incidentally), then it obviously becomes tedious to have to restate the trivial type signature for each constructor. Using GADTs style syntax it is possible to allow constructors with existentially quantified arguments with *no additional syntax needed*. It follows nicely from the standard syntax for type signature declarations (assuming explicit foralls), e.g. the following "normal" datatype declaration data Foo = forall a . Show a => Foo a which uses ExistentialQuantification syntax, could be written as data Foo where Foo :: forall a . Show a => a -> Foo which is syntactically just a normal type signature. The upside of deprecating ExistentialQuantification is thus that we keep the syntax cleaner, and we keep the old style of datatype declarations simple (as it should be, IMO). Anything fancier can use the GADTs syntax, which anyone that uses something fancier should be acquainted with anyway. The downside is that we lose one level of granularity in the type system. GADTs enables a lot more semantic possibilities for constructors than ExistentialQuantification does, and baking the latter into the former means we have no way of specifying that we *only* want to use the capabilities of ExistentialQuantification. My own take on that is that what we have now is a wart that should be removed, and that if we think that the latter is a problem then the way to go would be to split the monolithic GADTs extension into several semantic levels. There is of course also the downside that we break existing code, but that's a standard problem with improvement through deprecation which I will pay no mind. Discussion period: 2 weeks Cheers, /Niklas [1] http://www.haskell.org/pipermail/glasgow-haskell-users/2009-June/017432.html

12 23

Proposal: ExplicitForall
by Niklas Broberg 23 Jul '09

23 Jul '09

Hi all, (I'm writing this to several lists since it involves GHC (implementation of extensions), cabal (registration of extensions) and some future Haskell standard (formalisation of extensions).) In my quest to implement all known syntactic extensions to Haskell in my haskell-src-exts package, I've become painfully aware of the sometimes ad-hoc nature that these extensions have been added to GHC. This should not be taken as criticism per se, GHC is awesome and I'm sure a lot of thought and research has gone into all of these extensions. I think the problem (from my point of view) is rather that most of the extensions are only really "interesting" on a type system level, whereas the syntactic level is rather trivial, and thus the latter has (rightly) gotten far less formal attention. I hope my putting the light on these issues will be a help and a kickoff towards improving the state of formalisation of the known and registered (with Cabal) extensions. One of the most blatant and (to me) problematic such issues is the matter of using 'forall'. GHC has a number of extensions relating to the use of forall-quantified types in various interesting ways. With none of these extensions on, forall is not considered a keyword, so the syntax with explicit forall quantification cannot be used at all ('forall' is considered a varid). However, with *any* extension on that relates to forall-quantified types, forall is a keyword, and can syntactically be used in types *anywhere*. This doesn't mean all such types will pass the type checker, most of them won't in fact, but syntactically there is really no (or at least very little) difference. Conceptually, all of these extensions (specifically PolymorphicComponents, Rank2Types, RankNTypes, LiberalTypeSynonyms and ScopedTypeVariables (and strangely also ExistentialQuantification)) thus have one thing in common. They all enable syntactically forall-quantified types. They allow different uses of these types as far as the type system is concerned, but syntactically there is no difference between type and type (in fact there cannot be, as I discussed in a recent blog post [1]). Funnily enough there are also some uses of forall-quantified types that are common to all of these extensions - using a forall just to make polymorphism explicit in a type doesn't change anything as far as the type system is concerned, so e.g. the types '(Eq a) => a -> Bool' and 'forall a . (Eq a) => a -> Bool' are equivalent. The latter type can be given to a function when any of the listed six extensions are given, even if most of them have nothing to do with this at all! So, what I'm getting at is an idea that Isaac Dupree gave as a comment to my blog post. He said: "I wish there was a plain old ExplicitForall extension that enabled the keyword in types (without extending the type checker -- only like (id :: forall a. a -> a) would be allowed)". I think this is a really great idea. I find it conceptually appealing, since I think it covers exactly that blind spot that is the seemingly unintended intersection between all these extensions. And it also makes the separation of concern between the syntactic level and the type system more clear. Any formalisation of any of the type system extensions would not need to bother with syntactic details, but can simply be said to imply ExplicitForall. I would thus like to propose the following formalisation of the ExplicitForall extension: ========================================= ExplicitForall enables the use of the keyword 'forall' to make a type explicitly polymorphic. Syntactically, it would mean the following change to Haskell 98: * 'forall' becomes a reserved word. * '.' (dot) becomes a special (not reserved) operator. * The following syntactic rule changes: type -> 'forall' tyvars '.' type | context '=>' type | ftype ftype -> btype '->' type | btype gendecl -> vars '::' type It does not allow the use of explicitly polymorphic types in any way not already allowed by Haskell 98 for implicitly polymorphic types. ========================================= One thing to note is that I haven't touched the matter of ExistentialQuantification in the above. Syntactically this is a different beast entirely, and could well be handled separately, though it's really an artifact of the way we (by default) write our data type declarations. Using GADT-style declarations, existential quantification goes nicely along with the others by following the same syntactic rules for types, even though from a type system it is of course still quite different from the rest. But with the ordinary Haskell 98 declaration style, we could define the syntactic part of the ExistentialQuantification extension as the following: ========================================= ExistentialQuantification allows data constructors to take existentially quantified arguments. Syntactically, it means the following changes to Haskell98: * 'forall' becomes a reserved word. * '.' (dot) becomes a special (not reserved) operator. * The following syntactic rule changes: constrs -> econstr_1 '|' ... '|' econstr_n econstr -> ['forall' tyvars '.' [context '=>']] constr ========================================= My hope is that you'll all agree with me on the need and rationale for the ExplicitForall extension, and that my proposal for formalisation is good enough for adoption. I feel much less strongly about ExistentialQuantification, and would love to hear some more input on that matter, but I do think it needs to be addressed one way or the other. Thoughts? Cheers, /Niklas [1] http://nibrofun.blogspot.com/2009/06/whats-in-forall.html

3 4

Fwd: Generating valid Haskell code using the GHC API pretty printer
by Thomas Schilling 23 Jul '09

23 Jul '09

Forgot to include the list. ---------- Forwarded message ---------- From: Thomas Schilling <nominolo(a)googlemail.com> Date: 2009/7/22 Subject: Re: Generating valid Haskell code using the GHC API pretty printer To: Jan Schaumlöffel <jsch(a)informatik.uni-kiel.de> The pretty printer never prints { .. } for a do expression. You can control which things are printed unqualified by setting the "PrintUnqualified" part properly. The most straightforward way is to use GHC.mkPrintUnqualifiedForModule which only prints things qualified that are not imported in the given module. See 'withPprStyle' and 'mkUserStyle' in Outputable. That said, if you're trying to do source-to-source transformations you probably want to keep the original layout as much as possible. GHC's pretty-printer isn't designed for that. GHC's syntax tree has very accurate source locations, so you could start from there and build your own pretty printer. 2009/7/22 Jan Schaumlöffel <jsch(a)informatik.uni-kiel.de>: > Hello everyone, > > we are trying to use the GHC API for a source-to-source transformation > on Haskell programs. The result of parsing and typechecking a module > enables us to apply the transformation, but writing the transformed > module back using the pretty printer (Outputable) generates invalid > Haskell code. > > For one thing, since even the names defined in the current module are > fully qualified, the resulting code is not valid anymore. > > This can be worked around, but there is another issue: Simply reading > the following program and then writing it out using the pretty printer > renders the resulting code invalid. > >> module Main where >> main = do >> if True then putStrLn "longlonglonglonglonglongline" >> else return () >> longlonglonglonglonglonglonglonglonglonglonglongname $ "test" >> longlonglonglonglonglonglonglonglonglonglonglongname = putStrLn > > The result looks like this: > >> Main.main = do if GHC.Bool.True then >> System.IO.putStrLn "longlonglonglonglonglongline" >> else >> GHC.Base.return () >> Main.longlonglonglonglonglonglonglonglonglonglonglongname >> GHC.Base.$ >> "test" >> Main.longlonglonglonglonglonglonglonglonglonglonglongname = System.IO.putStrLn > > There are two different problems in this output: > > 1) the indentation of "if ... then ... else" violates the "do"-block > layout rule > 2) the indentation of the long function call is invalid > > It looks like those problems could be avoided if the pretty printer > could be configured to consistently use "do { ... ; ... }" notation, > but we have been unable to figure out how. Is there a canonical way > to use the GHC API to pretty print to valid Haskell code? > > Kind regards, > Jan > > Appended is our current code to execute the transformation above (the > module to be read is expected in a file "dummy.hs" for simplicity). > Please excuse if this might not be a minimal example. > > module Main where > > import GHC > import GHC.Paths > import Outputable > > main = do > x <- runGhc (Just libdir) $ do > dflags <- getSessionDynFlags > setSessionDynFlags (dflags { hscTarget = HscNothing, > ghcLink = NoLink }) > > target <- guessTarget "dummy.hs" Nothing > setTargets [target] > load LoadAllTargets > > graph <- getModuleGraph > let unparsedmod = head graph > > parsedmod <- parseModule unparsedmod > typecheckedmod <- typecheckModule parsedmod > let Just renamedsource = renamedSource typecheckedmod > (group,_,_,_,_) = renamedsource > moduledings = (ms_mod unparsedmod) > > return (showSDoc (ppr group)) > putStr $ x ++ "\n" > > -- > If you're happy and you know it, syntax error! > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > -- Push the envelope. Watch it bend. -- Push the envelope. Watch it bend.

4 3

Unpacking multi-type constructors
by Louis Wasserman 22 Jul '09

22 Jul '09

I think this is a feasible idea. Whether this is in fact a good idea is an entirely separate question, however, and I want feedback. Currently, I believe that an UNPACK pragma used on a multi-constructor type has no effect. For example, data Node = Node Int {-# UNPACK #-} !(Maybe Node) {-# UNPACK #-} !(Maybe Node) is the same as data Node = Node Int !(Maybe Node) !(Maybe Node) What I'd like is for this to translate into four constructors, one for each combination of constructors for the UNPACK'd fields: data Node = Node0 Int -- Nothing, Nothing | Node1 Int Node -- Just, Nothing | Node2 Int Node -- Nothing, Just | Node3 Int Node Node -- Just, Just The primary counterargument I can think of is that this can result in a single-constructor type being turned into a multi-constructor type, which runs the risk of interfering with GHC's sexcellent handling of single-constructor types. The countercounterargument is, of course, that the {-# UNPACK #-} pragma already behaves differently depending on the single-constructorness of the underlying type, and that the obligation is already on the programmer to check such things. For reference, could somebody point me to the place in GHC that currently takes care of {-# UNPACK #-} pragmas, so I could -- for instance -- figure out whether or not there's another reason that this idea isn't in place already? Louis Wasserman wasserman.louis(a)gmail.com

3 3

[relapse.dev@gmx.com: [Haskell-cafe] System.Mem.performGC leaks?]
by Don Stewart 22 Jul '09

22 Jul '09

Interesting. ----- Forwarded message from Neal Alexander <relapse.dev(a)gmx.com> ----- Date: Tue, 21 Jul 2009 18:48:38 -0700 From: Neal Alexander <relapse.dev(a)gmx.com> To: haskell-cafe(a)haskell.org Subject: [Haskell-cafe] System.Mem.performGC leaks? main = forever performGC The OS reported memory usage skyrockets. If i enable +RTS -S the GC statistics show the heap "live bytes" being constant. Is it accumulating statistics even when profiling is disabled (and can you turn that off), or is there something going on with the FFI call to performGC. Compiled with "ghc -O2 -fvia-C -optc-O2 -funbox-strict-fields -threaded" btw. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ----- End forwarded message -----

1 0