GHC 7.8.1 released | Hacker News Reader

GHC 7.8.1 released

haskell.org

249 pointsocharles101 comments

I don't recall ever being excited about a compiler release before, but this has got me excited. Typed holes, overloaded lists, pattern synonyms, new IO manager, new code generator, interruptible FFI calls, parallel compilation, and tons of other new features.

One thing I'm particularly excited about is the switch to use the system's dynamic linker instead of a custom one in GHCi. The custom linker GHCi used before didn't support some features used by C++ code, which meant that some of my FFI-based projects weren't usable in GHCi. This also affected other things that used a GHCi-like code path like Template Haskell and the GHC APIs used by ghc-mod/hdevtools. This will be huge for usability for me when working on projects that link to C++.

Hat tip to all the GHC developers for a truly amazing release!

The dynamic switch isn't without its pain points. In particular, the way we currently implement it leaves some things to be desired, and it's lead to some other rather unfortunate ramifications for Windows right now.

Truthfully, me and Simon now have reservations about if this is the right way to go, and we should instead invest more infrastructure into our own Linker (which, independently, got some nice bug fixes this time around - constructors and weak pointers now work, for example.) ELF support is quite complete (and very stable) for example. It's just a question of what's the most work.

[..] http://www.haskell.org/ghc/docs/7.8.1/html/users_guide/type-... [..]

This extension allows programmers to use the list notation for construction of structures like: Set, Map, IntMap, Vector, Text and Array. The following code listing gives a few examples:

['0' .. '9'] :: Set Char

[1 .. 10] :: Vector Int

[("default",0), (k1,v1)] :: Map String Int

['a' .. 'z'] :: Text

http://www.haskell.org/ghc/docs/7.8.1/html/users_guide/type-...

Woah! I did not know that was going to be included! Here's to hoping it makes as much a splash as OverloadedStrings did!

As a non-fan of OverloadedStrings, I'm not sure how I feel about this.

What are your objections to OverloadedStrings?

It can give unexpected/wrong results when working with Unicode strings.

A reasonable objection, but I don't see that it applies to OverloadedLists either directly or by analogy (though I could totally be missing something).

Can you elaborate? Perhaps you are talking about the Char8 ByteString instance? It was a mistake to declare that instance, I think.

Perhaps you are talking about the Char8 ByteString instance?

Yes. Data.ByteString.Char8.pack does not form an isomorphism with Data.ByteString.Char8.unpack. It is thus not interchangeable with String.

Example:

    Prelude Data.ByteString.Char8> putStrLn . unpack . pack $ "Российская Федерация"
    >AA89A:0O $545@0F8O

And here the correct result with Data.Text:

    Prelude Data.Text> putStrLn . unpack . pack $ "Российская Федерация"
    Российская Федерация

That's an issue with Data.ByteString.Char8, not with OverloadedStrings.

When you use OverloadedStrings in conjunction with Data.ByteString.Char8 it becomes OverloadedStrings' issue as well. Compile-time transformations are not supposed to break your program.

I don't think of it as a compile-time transformation but instead a weakening of the semantics of string literals. Without we have

    "foo" :: String

and with we have

    "foo" :: IsString a => a

much like

    3 :: Num a => a

It inherits all of the same weaknesses and strengths that we have with the Num typeclass.

Ahh, very good. Then perhaps our target of inquiry ought to be the IsString class. Ought it have some laws we can expect instances to follow, akin to the Monad laws? At the moment, we can write:

    instance IsString () where
    fromString = const ()

And there's nothing wrong with it!

Totally agree that it's a weak class. I'd love it if `IsList` were a subclass of `Foldable`!

That's true. Similarly, I expect that for types with weird Eq or Ord instances overloaded lists might give strange results. That said, those issues still exist when someone types

    pack "<unicode> string"
    fromList [1,2,3,4,4.000000000000000000000000001]

It just makes programs ambigious when reading. The amount of typing you save is the amount of type information the reader loses. It's okay if there's just one instance of IsString you're actually using, but if you're using few of them in the same module it turns out to not be satisfactory for my tastes.

That's pretty reasonable, yeah.

I think OverloadedStrings makes things more ambiguous. It's a power-feature, to be sure, but it also makes the use of Text and ByteString much more available in much the same way that numeric literals do (literally the same way, actually).

I think that sort of ambiguity is part of Haskell. It rescinds a bit on the HM promise of never having to write types, but Haskell has long rescinded on that in spirit and practice. It leads to a bit of beginner trouble, but, again, not any more than numeric literals do.

I welcome overloaded lists because I feel it'll make more libraries willing to expose Set-typed interfaces when that's the honest contract that should be upheld by the interface. That's what I want my types to tell me—not just what's syntactically convenient.

I somewhat agree on the last point. The temptation is often too great to use those horrible, horrible O(n^2) set functions (nub, difference, intersection) from Data.List just because of the immediate availability.

I've been playing around with the new PatternSynonyms extension. In combination with the existing ViewPatterns extension, I'm going to really have to change the way I think about API design. This is actually pretty fantastic.

    {-# LANGUAGE ViewPatterns, PatternSynonyms #-}
    
    import Data.Set as S
    
    -- patterns that a library might provide
    pattern x :< m <- (minView -> Just (x, m))
    pattern m :> x <- (maxView -> Just (x, m))
    pattern Null   <- (S.null  -> True)
    
    -- a really dumb test function using those patterns
    doubleMin :: (Ord a, Num a) => Set a -> Set a
    doubleMin (x :< s) = insert (2 * x) s
    doubleMin x = x

Ignore how dumb my test function is, and just focus on how lightweight it becomes to match views of the data structure. Figuring out what patterns to include my libraries is going to be a fun new design point.

I haven't had a look at the extension definition itself, but I find this really hard to read. Can you or someone else give an explanation of what's going on? It seems to me that the brackets are all wrong, I would've expected

    pattern (x :< m <- minView) -> Just (x,m)

but that's just basically view patterns/pattern guards. Basically I can sort of see what's going on here, but only in this specific case; I can't see how one uses this elsewhere.

The choice of character for unidirectional patterns isn't the greatest, I'll agree.

The PatternSynonyms extension enables two new top-level declarations, both declared with "pattern".

    pattern NestedJust x = Just (Just x)
    pattern NestedNothing = Just Nothing

That's the easier syntax of a bidirectional pattern synonym. They can be used both as patterns and as expressions.

    foo :: Maybe (Maybe Int) -> Bool
    foo (NestedJust 7)  = True
    foo (NestedNothing) = False
    foo _               = False

    bar :: Maybe (Maybe String)
    bar = NestedJust "hello"

There are a couple terrible examples. Bidirectional pattern synonyms must be valid as both expressions and pattern matches, or you get a compile error

My example was using unidirectional pattern synonyms. They allow any pattern match whatsoever as the body; the expression restriction is dropped because they aren't allowed to be used in expression contexts. They are defined using <- instead of =.

    pattern MinView x m <- (minView -> Just (x, m))

That's functionally the same as the :< example above, but possibly a bit simpler to read, because the precedence of the symbols is more obvious. It defines a pattern synonym named MinView that is translated to the view pattern in parens.

It's quite possible you were conflating view pattern syntax with pattern guard syntax as the source of your confusion.

For those who write large scale applications, web or otherwise, the mio io manager improvements should be especially exciting. See http://www.reddit.com/r/haskell/comments/1k6fsl/mio_a_highpe... for a prior discussion.

I was reading the paper and got stuck somewhere when I saw this:

> With Mio, realistic HTTP servers in Haskell scale to 20 CPU cores, achieving peak performance up to factor of 6.5x compared to the same servers using previous versions of GHC. The latency of Haskell servers is also improved: <snip> under a moderate load, reduces expected response time by 5.7x when compared with previous versions of GHC

> Available with GHC 7.8.1

Nice job.

I really want to get into Haskell, but I just don't understand it. The tutorial on the official site doesn't do it for me. Can anyone suggest alternative resources for learning? I'm used to C-like languages.

Thanks for all the responses. I'll start with LYAH.

http://learnyouahaskell.com/chapters

Learn You A Haskell For Great Good (free online book) is the most common recommendation for beginners.

I tried getting into haskell probably 3 times before it really stuck with me. After getting over the initial hump it's heavenly. I started with LYAH like others have recommended. Persistence!

Learn You a Haskell for Great Good! has already been recommended, which I would have said if it had not yet been.

There is also Real World Haskell [0]. It's a lot less long winded than LYaH, which is good or bad depending on how you like to digest information.

Also, check out FP Complete's FP Haskell Center [1]. It contains community written tutorials with inline runnable code examples, so you can really get a feel for Haskell by manipulating and playing with the examples right on the site.

[0] http://book.realworldhaskell.org/read/

[1] https://www.fpcomplete.com/business/fp-haskell-center/

I'm a big fan of http://learnyouahaskell.com/

Others have linked tutorials. I'm going to leave some advice: pretend like you're learning to program from scratch. Not just mentally but in how you invest. It will likely take some amount of time, it will likely happen in stages of progressively receding complete astonishment and confusion, and you will be served to be proud of silly things like getting simple programs to even compile.

Sounds kind of miserable, right?

That's why you should also prepare for it with some of that early curiosity and wonder that drove us all to learn programming to begin with.

Haskell is probably unlike anything you've used before.

This is most certainly the best advice you can give to someone coming from other languages. I constantly see people I very much respect for their skills in other programming disciplines get very angry and make otherwise irrational rants about Haskell because they can't translate their hard won skills over to this new model. Learning Haskell will make one feel like a beginner again, should just embrace that from the start.

After LYAH I learned a lot from doing as many of the 99problems set for Haskell as possible.

http://www.haskell.org/haskellwiki/H-99:_Ninety-Nine_Haskell...

When I learn something, I would like to simultaneously read several books on the same topic, so that I could learn same things from different perspective. It works great for me when I learn Haskell, Scala, and other things.

Here is the list of materials I used to learn Haskell:

1. LYAH, http://learnyouahaskell.com/

2. Real world Haskell: http://book.realworldhaskell.org/read/

3. Programming in Haskell: http://www.amazon.com/Programming-Haskell-Graham-Hutton/dp/0... (No one suggests this book, but I do think this book is well-written and concise.)

4. Video tutorial by Erik Meijer based on Programming in Haskell: http://channel9.msdn.com/Series/C9-Lectures-Erik-Meijer-Func...

5. Advanced topics: http://www.haskellforall.com/2014/03/introductions-to-advanc...

Edit: Format

One thing to keep in mind: Haskell is different enough that it's almost as hard as learning to program the first time.

To learn something that hard, you need to be exposed to it multiple times. You'll probably get overwhelmed even with LYAH, but give it some time and come back to it.

I can recommend reading SICP first if you know nothing about functional programming. It will likely help a lot. And forget everything you know from C-like languages (I'm not joking).

I recommend the 99 Haskel problems: http://www.haskell.org/haskellwiki/H-99:_Ninety-Nine_Haskell...

All questions have solutions you can learn from; most have multiple solutions. I have learned a lot from doing these problems and doing additional research where needed.

(This is in addition to the other good learning resources like the oft mentioned LYAH.)

Miran Lipovaca's LYAH is one of the best intro to programming, not just intro to Haskell, books I've read. He's great at explaining complicated technical concepts clearly.

I sincerely recommend against LYAH! It takes sooooooooo loooooong to get to the interesting bits that actually make Haskell worth learning an has so many try-to-be-funny examples that it makes you run away screaming... I tried going through it but it was literally oscillating between putting my mind to sleep and making wish to grab a chainsaw :) And the "humor" and "pretty pictures" don't help either... they were more like poignant guide to ruby, something that you either love or they annoy the hel out of you (this was for me), but either way they don't help the learning experience at all.

I suggest HFH ("Haskell Fast & Hard") as the introductory tutorial to start with instead. You can pick from 2 formats:

- http://yannesposito.com/Scratch/en/blog/Haskell-the-Hard-Way... - static all-in-one-page format with pretty pictures

- https://www.fpcomplete.com/school/to-infinity-and-beyond/pic... - split version, but with the ability to open snippets in their web based IDE

...after this, Real World Haskell is probably the next step: http://book.realworldhaskell.org/read/ (I'm still at this step).

I accidentally upvoted you, but I disagree. LYAH is a great book to actually read through, and I enjoyed the humor. real world haskell introduces things without explaining and it's quite confusing and inconsistent.

Why would downvote for disagreeing? GP is actually a well written comment, and very much deserves the upvote.

I concur, LYAH was, for me, not a terribly useful intro to Haskell.

Running through some chapters of Real World Haskell online, however, is proving to be a bit of an eye opener ;-)

Might just be that I could care less about hand drawn illustrations and the occassional somewhat humerous aside.

YMMV, many seem to love LYAH.

To me, the core of Haskell is that: "Haskell is C with one semi-colon per function."

This forces you to put all your code into method signatures. This, in turn, means Haskell (or C, if you follow the 1 semicolon rule in C) can understand almost everything about your program.

If you actually follow the 1 semicolon rule in C, you'll get very verbose syntax. All of Haskell's syntax is in service of making programming in this style palatable.

If you want an alternative opinion from somebody who

1. Has taught a lot of Haskell

2. Thinks LYAH is better as a reference than a step-by-step method for learning Haskell

Then see my Learning Haskell gist here (it includes Haskell Fast & Hard, and other things too).

https://gist.github.com/bitemyapp/8739525

If anybody is learning Haskell and needs help, please email me.

Edit: I agree with nnq, I think LYAH moves too slowly and fails to show you what about Haskell is truly different and worthwhile in a compact enough format. That said, it is great as a reference as the explanations of concepts are stand-alone. (unlike RWH which is more project-oriented)

Edit2: You are going to feel a bit lost after Haskell Fast & Hard. This is natural. That's why I have you do the NICTA course. It firms things up.

Edit3: I think RWH is a great reference as well, but the mid-to-late chapters have a bit of an "in media res" thing going on because there are projects being walked through cross-chapter. That said, it has a very nice and simple example of, "pre-monads, ugly code; post-monads, pretty code". RWH also covers topics that you'll care about if you're doing Haskell in production.

Cool, i'm going to look at that gist for this years "try to learn haskell... again" attempt. :)

I do it every year but hit io monads and my mind continually just has a core dump. Some year I hope to climb everest.

>I do it every year but hit io monads and my mind continually just has a core dump

Stop doing that. I explicitly say in my gist:

"Most of all, don't sweat the stuff you don't understand immediately. Just keep moving."

IO is not important. It behaves no differently at a basic level than any other monad. Monads themselves are just an interface.

Don't put the knowledge on a pedestal, just keep hacking Haskell. It'll all come with time.

This blog post of mine might lend some intuition for monads (including IO): http://bitemyapp.com/posts/2014-03-24-monads-bind-join-actio...

But don't get stuck. It doesn't matter. Just write Haskell code. The compiler won't let you do anything too crazy anyway.

No one's mentioned the wikibook. I've not read through it much, but a colleague found it far more readable than LYAH: http://en.wikibooks.org/wiki/Haskell (I loved LYAH myself, though, so YMWillProbablyV).

Also, there's no substitute for talking to people. Hop on the Haskell Beginners mailing list (http://www.haskell.org/mailman/listinfo/beginners) or drop by the IRC channel (#haskell on freenode), where people couldn't be friendlier.

Don't bother with LYAH. I learned Haskell from a lecture created by one of the creators of the language, Philip Wadler: https://www.youtube.com/playlist?list=PL4C1D41CB47EED318

I'm enjoying Learn You a Haskell.

Then again, that might be because when I looked into Haskell, I realised it was the language I wished to create.

(hi!)

You might like this:

http://www.haskell.org/haskellwiki/Haskell_Tutorial_for_C_Pr...

And the Gentle Introduction is not very gentle but is a good reference:

http://www.haskell.org/tutorial/

I've found the "24 Days of Hackage" series incredibly useful - each day is a brief introduction to a useful Haskell library, many of which show off features of Haskell that aren't available in 'standard' languages. Even better, each one comes with working example source on GitHub, so you've got a starting point if you do want to experiment.

http://ocharles.org.uk/blog/

(I'm a Haskell beginner, currently experimenting with using Scotty, Persistent and Esqueleto to make a web API - and these articles have been so useful to me - I'm finally getting my head around monad transformers, using them to extend the standard Scotty one. Proud moment for me.)

I'm lurching through the wikibook: http://en.wikibooks.org/wiki/Write_Yourself_a_Scheme_in_48_H... with a side order of the Haskell Report/Reference for when things are not clear to me.

Both are helping my limited experience of Haskell greatly.

I'm intrigued by "full iOS support." Does this mean it's now possible to write iOS apps using a Haskell backend?

Assuming it has something to do with this[0] but I'd be interested to know as well.

[0]: https://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompilin...

"In particular, GHC now has all the necessary patches to support cross compilation to Apple iOS, using the LLVM backend."

Yes - you can now compile Haskell code to run on iOS. There are still a few unusual steps that involve ffi but its pretty easy to get a trivial project up and running. I have an unfinished project that shows the process. https://github.com/schell/blocks

Yes. Everything but certain naive use of template Haskell or use of ghci is supported for targeting IOS. There's also some related engineering to provide android support

While this is nice, it results in a big static lib(27M) to include in your app. This might be okey for some games, but maybe not for small apps. I was very interested in a Haskell app, but eventually gave up because of this...

the twitter app is 30M, we have already past the point of sensible app sizes. edit: fb messenger is 60M, a ghc-ios app with the elm compiler baked in is 24M.

To me that makes it clear that a minimum size of over 20M is a serious problem.

How crazy would it be if the Twitter app was over 50M, or Facebook Messenger over 80M?

(I should not have said "serious problem", I should have said "notable barrier to adoption." That people have made this possible at all is fantastic.)

I'm also intrigued. How would one program for iOS in a practical sense with Haskell? A great deal of iOS programming, as I understand it, is navigating the APIs and libraries provided by the SDK... is this a simple task in Haskell? The FFI is something I haven't really dealt with much yet. I guess people could/will start writing wrapper libraries?

Haskell has one of the best FFIs I've ever seen; calling C code from Haskell is quite trivial, and you can write all of the necessary wrapper code and objects (such as automatic memory management or object destruction) in Haskell using common wrappers.

I'd also highly recommend c2hs for writing new wrapper libraries.

Part of the problem is that iOS APIs tend to be Objective-C, which is somewhat harder to wrap in Haskell.

Not really, it's quite easy to call Objective-C methods (or more correctly, to send messages to Objective-C selectors) and perform other Objective-C-related tasks from C. See: https://developer.apple.com/library/mac/documentation/Cocoa/...

This is actually what the Objective-C compiler does. It translates your Objective-C code to C method calls.

It's not that easy. I mean, just sending a message could entail one of objc_msgSend, obj_msgSend_stret or objc_msgSend_fpret, and which one you want to use is not always as clear-cut as you might prefer (http://www.sealiesoftware.com/blog/archive/2008/10/30/objc_e...). And then there's the hassle of defining classes dynamically, which entails six function calls just to create a class with one empty method, and one of those essential functions is not actually provided for you AFAIK unless you're using Apple's compiler where it's a builtin, so you'll need to write it yourself.

It's not ridiculously hard, but it's somewhat less easy than normal C FFI.

The other hard part about it is that Haskell's FFI doesn't support variadic functions in a friendly way, which makes argument passing that much trickier.

There is a similar problem with objc_msgSend in C: Methods with certain argument types can't be called with a normal objc_msgSend(). Instead, you need to create a specifically typed function pointer and assign objc_msgSend to it. I think a similar solution would be necessary with Haskell.

I'd appreciate seeing a link to an example of this. I put a decent amount of work (a few years ago) into writing some bindings in Haskell to the objc runtime, but ended up shelving it until I could come up with a satisfactory solution to the variadic function dilemma.

Here are a couple of Stack Overflow answers that illustrate how you do it in Objective-C:

http://stackoverflow.com/a/2573949

http://stackoverflow.com/a/18689338

If you're interested in the nitty-gritty of how objc_msgSend works, bbum from Apple wrote up a great low-level walkthrough a few years back: http://www.friday.com/bbum/2009/12/18/objc_msgsend-part-1-th...

If you just need to call variadic functions with a specific parameter list determined at compile time, that's easy with the existing FFI; just write a prototype for the function for any given set of arguments you want to call it with. (For instance, you can have an FFI binding printf_int_float :: CString -> CInt -> CFloat -> IO CInt .)

If you really need to construct calls at runtime and you don't know the argument list at compile time, there's a Haskell binding to libffi. However, you generally only need that if you're writing a language interpreter or similar.

Doesn't calling C code interact poorly with green threading? (I assume that handlers that make it act slightly sanely exist, but I imagine the cost of setting up native threads for FFI is rather high.)

Native threads for FFI calls are pooled. It's not cheap, but it's not too expensive either.

I think the idea is that you would use the standard tools for the edges of the program with a Haskell core underneath handling the thinky bits. (I have no experience at all doing this, but it seems like the natural use case.)

I'll be giving a workshop on using GHC iOS at BayHac 2014 [1] along with a demo of http://tree.is which is built entirely on top of it!

[1] http://www.haskell.org/haskellwiki/BayHac2014

I know enough about Haskell to be excited, but recently, I implemented a few systems with F# and am really happy with the language. If we forget about the .net/MS thing (and all the hatred that comes from that), are there real true advantages of going Haskell for a greenfield project over F# ? (I have a couple heavy algorithm heavy Haskell projects done, but having worked with F# more and more, I feel like it is so much nicer as a modern, not bend over your back to deal with the purity/lazy aspects language than Haskell).

One really cute feature that some systems folks might like is there's now support for calling the CPU/hardware prefetch instruction where applicable. http://www.haskell.org/ghc/docs/7.8.1/html/libraries/ghc-pri...

Even better, if you use vector library, prefetch instructions are automatically (and nearly optimally) inserted for your loops written in higher-order functions like fold.

Details here: http://research.microsoft.com/en-us/um/people/simonpj/papers...

Nope. That's not in the release version. Simd is still second class in ghc. Should be viable for ghc 7.10 though. Note well, the prefetches in that paper aren't optimal. In many cases prefetch is over issued.

You should only use prefetch when benchmarks show that the hardware prefetch isn't performing up to sniff. Or when your access pattern for data doesn't have good locality and doesn't resemble a linear arithmetic sequence. (Just rules of thumbs mind you. For more precise heuristics, please read your CPU vendors optimization manual. The intel manual has quite a few tricks that should apply to most modern CPUs overall)

A bit off topic- why is GHC so large? I recently noticed it was over three times the size of gcc (for amd64, in an .xz archive).

This might be interesting to you: http://stackoverflow.com/questions/4858585/why-is-ghc-so-lar...

Now I'm kind of curious. The GHC is listed there as being 113 megabytes. When I try to install it on Arch Linux, the size is listed as 736MB! What in God's name is Arch doing to nearly septuple the size of this package— and more to the point, does anyone know any way of getting it to not do that? I'd very much like to learn Haskell, but taking up that much space on my laptop's SSD is a dealbreaker.

That's because they're measuring the tarball, which is a worthless metric anyway (for example, we just switched to supporting .tar.xz, which reduced the size of Linux binary distributions close to 50% for a ~65MB total. But that doesn't tell you anything about what's inside.)

The unpacked binary distribution is closer to 1GB, which sounds about right. I speculate Arch Linux is doing a regular build with nothing special.

If 1GB is undoable for your laptop (which I find odd, as someone even on a 100GB device), then that's unfortunate. You're best to wait for some other build with things removed or to just build it yourself (for example, no dynamic linking).

Short answer: GHC is not just a compiler; it's also a rather large library.

I want to find a job as Haskell programmer!

I've projects I'd be willing to delegate, if I can pay you sufficiently little...

Sharing izietto's wish, how might one contact you?

You can shoot me an email (davidleothomas@gmail.com) or hit me on irc (davidthomas on freenode - I typically lurk in #haskell and #snowdrift, amongst other places). I don't want to get hopes up too high - sufficiently little isn't going to be much in the short term.

Is GHCJS easy to install now? I'm very excited about that.

Luite is probably going to announce something like that in a few days. Ghcjs getting ready for general release was blocked by ghc 7.8.1 not being released.

Great! Can't wait until the next release of the Haskell Platform now.

Don't.

There's no benefit to handcuffing yourself to the platform. Just install ghc and cabal, and enjoy yourself.

... and use cabal sandboxes! Otherwise the "enjoy yourself" bit may be a little short-lived ;)

What will be the easiest way to get GHC 7.8.1 running alongside the official GHC packages for Debian (specifically Jessie)?

Should I download a package from http://deb.haskell.org/? If so, where can I find 7.8.1?

That is maintained by an active ghc contributor, so should be safe to use!

GHC 7.8 is already packaged in Debian experimental, so if you're running current testing, you may find it easiest to just add sources for experimental and sid, set the default release to testing (so you don't upgrade anything else), and then install GHC 7.8 directly. You'll end up upgrading a pile of Haskell packages to versions from experimental, but mostly not the rest of your system.

You can use these PPAs from our friend, Herbert: https://launchpad.net/~hvr/+archive/ghc/

They are packaged for Ubuntu, technically (12.04 Precise) but you can just add the apt-repository line to your `sources.list` and it will work fine, and plenty of people are doing this.

A repository for the STABLE branch will eventually appear on http://deb.haskell.org, but I'm not sure when Joachim will do this.

The binary distributions install alongside your system packages or other bindists quite nicely (they might overwrite the /usr/bin/ghc symlink, but that's it) and you can select which ghc version you want to use when using cabal with the `-w` flag. Each will keep a separate package db, etc. So be bold!

Thank you for your comment. I've ended up installing 7.8.1 from the binary distributions from the GHC site: http://www.haskell.org/ghc/download_ghc_7_8_1

As easy as:

  tar -xJvf ghc-7.8.1-i386-unknown-linux-deb7.tar.xz
  cd ghc-7.8.1
  ./configure --prefix=/opt/ghc-7.8.1
  make install

This is great news for all 5 haskell programmers!

Just kidding, Haskell is a great language, it's unfortunate that the tooling is still way behind (at least on Windows) and that it isn't used much.

Reply on news.ycombinator.com