- Glasgow-haskell-users

source/build separation
by Rustom Mody 15 Nov '11

15 Nov '11

I am building ghc from source. The building page http://hackage.haskell.org/trac/ghc/wiki/Building/Using#Sourcetreesandbuild… mentions lndir for separating source trees from build trees. Given how much detail is generally given for individual commands eg http://hackage.haskell.org/trac/ghc/wiki/Building/GettingTheSources maybe it would be nice to have a (typical?) lndir command also given? Also there is a mention about using a local git clone here http://hackage.haskell.org/trac/ghc/wiki/Building/GettingTheSources Arent these two alternative ways with similar intent - viz. keeping source pristine and separating build 'messiness'? Or do people use both git (local) clone + lndir? If so why? Rusi [ghc noob here: Please tell me if this is the wrong list to ask this kind of question :-) ]

3 2

ANNOUNCE: GHC version 7.2.2
by Ian Lynagh 14 Nov '11

14 Nov '11

============================================================= The (Interactive) Glasgow Haskell Compiler -- version 7.2.2 ============================================================= The GHC Team is pleased to announce a new bugfix release of GHC, 7.2.2. The 7.2 branch is intended to be more of a "technology preview" than normal GHC stable branches; in particular, it supports a significantly improved version of DPH, as well as new features such as compiler plugins and "safe Haskell". The design of these new features may evolve as we get more experience with them. The changes in this release, relative to 7.2.1, are: * All packages are now trusted by default. If you wish to make use of Safe Haskell, you will need to manually untrust packages that you do not wish to trust. * An optimiser bug which can cause segfaults has been fixed. * A native code generator bug which can cause segfaults on x86 and amd64 has been fixed. * A race condition in the runtime system that can cause segfaults has been fixed. * Exception handlers are now run in the mask state, rather than the maskUninterruptible state. Fixes a bug that could cause the GHCi debugger to hang amongst other things. * The shutdownHaskellAndExit function now immediately exits, even if hs_init has been called multiple times. * A bug arising when using type signature declarations in Template Haskell splices has been fixed. * A bug arising when using class instances in Template Haskell splices has been fixed. * Incorrectly encoded text at the end of a file is now handled correctly. * The base package is now version 4.4.1.0 (was 4.4.0.0). * Haddock is now version 2.9.4. 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. 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

3 4

Re: instance union decl
by Serge D. Mechveliani 12 Nov '11

12 Nov '11

The general idea of my recent instance union proposal is that for a single polymorphic type T, sometimes it is natural to define several instances by a single `instances' declaration. ------ Sergei

1 0

GHC 7.2.2 RC 1
by Ian Lynagh 12 Nov '11

12 Nov '11

We are pleased to announce the first release candidate for GHC 7.2.2: http://www.haskell.org/ghc/dist/7.2.2-rc1/ This includes the source tarball, installers for OS X and Windows, and bindists for amd64/Linux, i386/Linux, amd64/FreeBSD and i386/FreeBSD. 7.2.2 will be a minimal bugfix release, fixing only bugs that cannot be worked around. Please let us know if you find any showstoppers. Thanks Ian, on behalf of the GHC team

8 11

sendWakeup bug #5553
by Bit Connor 11 Nov '11

11 Nov '11

Here's a bug I submitted 4 weeks ago, and there hasn't been much activity or responses regarding it since then: http://hackage.haskell.org/trac/ghc/ticket/5553 It causes the error message: ghc_sendWakeup_bug: sendWakeup: invalid argument (Bad file descriptor) It would be great if someone could take a look at this, or at least verify that you are able to reproduce the error using the test code provided in the bug report. Thanks, Bit

2 1

Should GHC default to -O1 ?
by Daniel Fischer 09 Nov '11

09 Nov '11

On the haskell-cafe as well as the beginners mailing lists, there frequently (for some value of frequent) are posts where the author inquires about a badly performing programme, in the form of stack overflows, space leaks or slowness. Often this is because they compiled their programme without optimisations, simply recompiling with -O or -O2 yields a decently performing programme. So I wonder, should ghc compile with -O1 by default? What would be the downsides?

11 13

Re: Records in Haskell
by Wolfgang Jeltsch 08 Nov '11

08 Nov '11

Am Montag, den 07.11.2011, 17:53 +0000 schrieb Barney Hilken: > Here is my understanding of the current state of the argument: > > Instead of Labels, there will be a new kind String, which is not a > subkind of *, so its elements are not types. The elements of String > are strings at the type level, written just like normal strings. If > you want labels, you can define them yourself, either empty: > > data Label (a :: String) > > or inhabited > > data Label (a :: String) = Label > > these definitions give you a family of types of the form Label "name", > in the first case empty (except for undefined), in the second case > inhabited by a single element (Label :: Label "name") > > There are several similar proposals for extensible records defined > using labels, all of which (as far as I can see) could be defined just > as easily using the kind String. The problem with this approach is that different labels do not have different representations at the value level. In my record system, I use label definitions like the following ones: data MyName1 = MyName1 data MyName2 = MyName2 This allows me to pattern match records, since I can construct record patterns that contain fixed labels: X :& MyName1 := myValue1 :& MyName2 := myValue2 I cannot see how this could be done using kind String. Do you see a solution for this? A similar problem arises when you want to define a selector function. You could implement a function get that receives a record and a label as arguments. However, you could not say something like the following then: get myRecord MyName1 Instead, you would have to write something like this: get myRecord (Label :: MyName1) Whis is ugly, I’d say. Yes, Simon’s proposal contains syntactic sugar for selection, but this sugar might not be available for other record systems, implemented in the language. The situation would be different if we would not only have kind String, but also an automatically defined GADT that we can use to fake dependent types with string parameters: data String :: String -> * -- automatically defined A string literal "abc" would be of type String "abc" then. However, I am not sure at the moment, if this would solve all the above problems. Best wishes, Wolfgang

6 7

Compiling using gmake
by Christian Brolin 08 Nov '11

08 Nov '11

Hello I try to set-up a gnu makefile for compiling Haskell programs with GHC. I want to generate dependencies automatically and I want to put my object (.o) files in a binary specifc directories to be able to compile for different architechtures. The problem is when GHC derives the dependencies it names the object file for the Main module to Main.o and not filename.o as it does if I don't specifiy an odir. This gives me two problems, first I cannot have more than one Main module in the same directory as I often need, e.g. for different test programs. The second problem is that it doesn't match my compile command which always names the object files after the the source files by just changing extensions from .hs to .o. So gmake does not recognize dependencies from my Main modules to other modules. I am stuck here. Any ideas?

3 2

Re: Way to expose BLACKHOLES through an API?
by Ryan Newton 07 Nov '11

07 Nov '11

Jan voted for the explicit "lockAndBlackhole" version as safer. I realize that for the Bytestring example all you would want to "gently" consume what is already available is WHNF detection alone. In that scenario you don't want to evaluate anything, just consume what is already evaluated. I would propose that when you do want to explicitly and actively blackhole something that that call be non-blocking (i.e. if someone else has already blackhole'd you don't wait). So the state machine would go: tryAcquire x = case unsafeRTStatus x of Blackhole -> return Nothing Unevaluated -> do b <- tryBlackhole x if b then return (Just x) else return Nothing Evaluated -> return (Just x) >> It would simply return Nothing if the value is BLACKHOLE'd. Of course >> it may be helpful to also distinguish the evaluated and unevaluated >> states. Further, the above simple version allows data-races (it may >> become blackhole'd right after we evaluate). An extreme version would >> actively blackhole it to "lock" the thunk... but maybe that's overkill >> and there are some other good ideas out there. > > I'd submit that your latter suggestion is far safer: return Nothing > unless we successfully blackhole the thunk or find that it's already > been evaluated. We actually *know* the blocking behavior we'll get, > and it's behavior we can't easily obtain through any other mechanism > (eg we'd have to add multiple unsafe indirections through mutable > cells into the lazy bytestring implementation to obtain the same > behavior in any other way, and essentially write out the laziness > longhand losing the benefits of indirection removal and so forth). >> A mechanism like the proposed should, for example, allow us to consume >> just as much of a lazy Bytestring as has already been computed by a >> producer, WITHOUT blocking and waiting on that producer thread, or >> migrating the producer computation over to our own thread (blowing its >> cache). > > For that you probably want WHNF-or-not detection as well (at least if > you want to schedule streaming of computation.

1 0

problems with impredicativity
by Wolfgang Jeltsch 07 Nov '11

07 Nov '11

Hello, this code is accepted by GHC 7.0.4: > {-# LANGUAGE ImpredicativeTypes #-} > > polyId :: (forall a. a) -> a > polyId x = x > > polyIdMap :: [forall a. a] -> [forall a. a] > polyIdMap xs = fmap polyId xs However, this one isn’t: > {-# LANGUAGE ImpredicativeTypes #-} > > polyId :: (forall a. Maybe a) -> Maybe a > polyId x = x > > polyIdMap :: [forall a. Maybe a] -> [forall a. Maybe a] > polyIdMap xs = fmap polyId xs Is there a way to make it accepted? Best wishes, Wolfgang

3 5