The Illustrated GHC [pdf]

http://takenobu-hs.github.io/downloads/haskell_ghc_illustrated.pdf

by dons • 12 years ago

58 11 12 years ago

takenobu-hs.github.io

amelius3• 12 years ago

As someone interested in functional programming and compilers, I recently tried to use GHC's intermediate output. However, I got a little disappointed about the documentation that's available for compiler writers. From what is essentially a research compiler, I'd expected a little higher standards, also in the department of available tools, and examples. In other words, the experience came too close to what I would call "hacking".

Furthermore, the "Core" language is, I believe, for many purposes, more complicated than necessary (e.g., it is typed). It would be nice if there were a simpler alternative, e.g., for small projects.

Of course, I could be wrong about this (perhaps I looked in the wrong places), but this is just what I noticed.

Besides this, of course, Haskell is a cool language, and GHC an awesome compiler! :)

tome• 12 years ago

Core is just a desugared Haskell. Do you know there's another much simpler intermediate language called STG?

thoughtpolice2• 12 years ago

As someone interested in functional programming and compilers, I recently tried to use GHC's intermediate output. However, I got a little disappointed about the documentation that's available for compiler writers. From what is essentially a research compiler, I'd expected a little higher standards, also in the department of available tools, and examples. In other words, the experience came too close to what I would call "hacking".

We don't really emphasize or support people using the intermediate language in an external way very well. They're parts of the compiler that are intimately and deeply tied to other internals elsewhere, and it's not really an explicit design goal that those components be reusable in a general way.

Now, people do use GHC for this (years ago I even helped write a compiler that transformed GHC's core language into a whole-program IR that was compiled to C), and we do have an API you can use to leverage the compiler, but overall the amount of people using it for things like this, vs using it for things like dynamic loaders or typechecking utilities (such as ghc-mod) are very small.

In fact, just last year we removed 'External Core' from GHC, which was a way of serializing the Core representation to disk. Why? Because it was actually broken for close to two years I think, and nobody ever really complained or fixed or wanted to support it! And after a discussion, we didn't want to support it either. It has been used, but when it bitrots that bad, I think it's clear this isn't one of the largest driving use cases for the compiler.

That said, we could improve the documentation a lot, and add a lot more examples. But I don't think there ever has been (or probably will be) a huge push to make the core IRs reusable in an easy way. It's simply not a high priority design goal.

Furthermore, the "Core" language is, I believe, for many purposes, more complicated than necessary (e.g., it is typed). It would be nice if there were a simpler alternative, e.g., for small projects.

The Core language being typed is a good thing for GHC - it makes it easy to turn on an internal typechecker and determine if the compiler has produced invalid IR, your optimization pass did, etc. It adds a lot of safety to your produced programs when you can ensure they type-check in a sane way.

This component, along with the core linting passes, have likely caught an _innumerable_ amount of optimization and desugaring bugs over the years, while being extremely low cost to support and use. Overall, typed Core has been a very huge win for GHC, and I don't ever see us adopting a different route. In fact, it's planned for our Core language to get an even fancier (dependent) type system not far off in the future. :)

amelius3• 12 years ago

I agree that the number of potential users for this particular use of GHC is small. But as with everything, it are the small groups of people that produce the most interesting things ;)

I don't think an external format (serialized Core) is even necessary. Just a well-documented API would be nice. I'm hoping that somebody could write a set of examples, and put those in a test-suite so that it keeps getting updated whenever something breaks it.

I also agree that typing is extremely useful. But for small research projects, it can get in the way of the actual goal.

dons• 12 years ago

There are several papers on why GHC uses a typed intermediate representation-- System Fc-- safety being the main reason.

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

An untyped representation is "just code", and that way lies madness. Bugs at least.

agumonkey• 12 years ago

GHC STG has many articles about it:

The 1992 SPJ paper http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=70D... (http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.53.3...)

https://www.google.fr/search?q=spj+ghc+stg -> http://lambda.jstolarek.com/2013/06/getting-friendly-with-st...

Also: https://ghc.haskell.org/trac/ghc/wiki/ReadingList

jamesfisher• 12 years ago

This looks great, but needs some interpretation, like an accompanying talk. I got lost in box-and-line diagrams which I did not know how to interpret.

An introduction to GHC which I found helpful is its AOSA chapter: http://www.aosabook.org/en/ghc.html

hardwaresofton• 12 years ago

Fantastic in depth PDF. While lacking the talk (as others have mentioned) I was able to determine in large strokes what's going on at the lower layers of Haskell. I particularly found the FFI interface section (ex. the breakdown of a call to getLine) extremely interesting/useful.

While I think real understanding will come if/when I have to actually wrestle with the lower layers of GHC (or am contributing to the source code or something), this served as a great overview, and a quick explanation of how Haskell "really" works.

mcguire• 12 years ago

I haven't looked at the source; is GHC using both C-- (http://www.cminusminus.org/) and LLVM?

The Illustrated GHC [pdf]

Related Stories