Architecture of Glasgow Haskell Compiler

In one of the previous posts I mentioned that the second volume of The Architecture of Open Source Applications contains chapter about Glasgow Haskell Compiler by Simon Marlow and Simon Peyton Jones1. I read this chapter yesterday and I must say it was insightful and interesting. It gives a general view of GHC architecture and it does so very effectively. Things are explained starting from high-level structure and then going into details about some selected parts of the compiler. There’s a nice overview of the compilation pipeline. This pipeline contains many steps that you won’t find in most books about compilers. Since I’m taking the Compilers course at Stanford it is nice to see how theory differs form practice :) What I consider as the most interesting in this paper is the discussion of the design choices made by the GHC creators and how these choices affect what GHC and Haskell are today. Authors also share some of their development practices, which I find very valuable, mainly because GHC is a project developed mostly by 2-3 people for over 20 years and it managed to be successful and extendible. This means that authors got some real experience about what works in real project and what doesn’t – I’m willing to follow their advices.

The paper is 29 pages long. It reads fairly quickly. It took me about 3,5 hours to get through, mostly because I was googling around trying to find out more about things that were new to me or things I didn’t understand. This means that while reading the paper I was also trying to figure out more about Core and find out what the hell is STG and Cmm. I’d like to get deeper into the architecture of GHC and I think this general overview is a nice introduction. In fact all the information in the paper – and much much more – can be found in the Commentary section of GHC wiki.

  1. There’s also PDF draft version of this paper. I didn’t notice any differences between the draft and the final version []

Haskell IDEs, Part 2: EclipseFP

In the previous post I wrote about using Emacs as a Haskell development environment. Today we’ll take a look at EclipseFP, a plugin that enhances Eclipse with Haskell support. Let’s begin with a brief overview of Eclipse.

If you ever programmed in Java than you almost certainly know Eclipse. This is one of the most popular IDEs for that language and in my personal opinion it’s the best one, much better then crappy NetBeans. Originally it was a project started by IBM, but it’s currently managed by the Eclipse Foundation. Eclipse is written in Java, uses native OS look-and-feel thanks to SWT (Standard Widget Toolkit) and has modular architecture that allows it to be extended with plugins. There are a lot of plugins for Eclipse, just as there are many extensions for Emacs, e.g. they allow to extend basic installation with support for version control systems or integrate with bug tracking and team collaboration software. Most importantly however plugins allow to use Eclipse as an IDE for languages other than Java (among them Haskell1). When I learnt Eclipse years ago it greatly boosted my efficiency as a programmer. Great keyboard shortcuts, good Test Driven Development support, refactoring and code generation capabilities allowed me to focus on important things relieving me of many repeatable tasks. There are also some downsides, one of them being the plugins: install too many and Eclipse will get cluttered with tens of additional options and menus. This is not a major problem though and when I start with a new programming language I usually begin by searching for Eclipse plugin (I admit that recently I also check Emacs extensions). Since I’m very used to Eclipse, with the learning curve already far behind me, I’m biased towards it.

Let’s see what EclipseFP has to offer. Installation turned out to be tedious, since the plugin requires many additional libraries from Hackage. If you already have them – and chances are that you have Hoogle, HLint or QuickCheck – this will be easier, but I had none, so it took some time (nothing complicated though). First problem appeared right after installation. Each time I started Eclipse, Hoogle reported that it has no database and asked if it should be built. Telling Hoogle that it should do it gave no result and the message reappeared each time Eclipse was started. It turned out that the database couldn’t be built because of permissions. Hoogle was installed system-wide and required root privileges to write the database somewhere in /usr directory, while Eclipse was run as normal user. Building the database as root from the command line solved the problem.

List of EclipseFP features is long: syntax highlighting, autocompletion (could be better though), HLint and Hoogle integration, GHCi integration, cabal file editor, profiling support, exporting Haddock documentation – to name some of them.  You can of course benefit from standard features of Eclipse as well as other plugins, e.g. using SVN or GIT integration in your Haskell project. Here’s a glimpse at EclipseFP in action:

No much surprise here: editor with multiple tabs, overview of project structure on the left, GHCi at the bottom. The only thing you may find odd is lack of menus and toolbars. These were disabled by a plugin that allows Eclipse to run in fullscreen mode to use as much screen space as possible. Even with this plugin enabled and editor window maximized (panes at bottom and left can be closed) there’s still less code on the screen comparing to Emacs. Emacs has 37 lines, EclipseFP and Leksah have 32 lines, but that of course depends strongly on your settings. Syntax highlighting could be better in EclipseFP. Both Emacs and Leksah offer more. An important thing to note is very good cabal build system integration. First of all, cabal file editor is non intrusive, so if you edit your files by hand, then use a graphical frontend, and then go back to hand editing you won’t notice anything2. EclipseFP also notices missing build dependencies in the cabal file and can automatically add them for you.

Concluding, EclipseFP nicely integrates Haskell development within Eclipse framework. If you ever developed Java and enjoyed Eclipse, then you must try out EclipseFP. I found EclipseFP much easier to use than Emacs for developing a larger project, most likely because I have many years of Eclipse experience vs. couple of weeks of Emacs experience. I still prefer Emacs to code some simple stuff that fits in one file, but I’m not giving up on Emacs as a project development environment3. Some things in EclipseFP could be improved – syntax highlighting is certainly one of them – but I haven’t found anything that I would consider a serious drawback. One thing that concerns me is the fact that EclipseFP is at the moment a single-person project (it is developed by JP Moresmau). Currently the development cycle seems to be quite stable, but I learnt that such projects can die instantly when the sole developer abandons them. It’s a pity there is no community around this project. I think this can be caused by the fact that it’s aimed at Haskell programmers, but you actually have to be a decent Java developer with solid knowledge of Eclipse RCP to contribute. I hope that I am wrong and no such thing will happen, since EclipseFP seems to be the most reasonable choice for people who want to develop Haskell but don’t fancy learning Emacs.

  1. In case you’re wondering, there are plugins for other functional languages: Scala (it’s a mature plugin and works decently), Erlang (this plugin on the other hand was quite buggy and I had to remove it), Clojure and Scheme (I use Emacs for LISP so I don’t know about these two).

    []

  2. As you’ll see in the future post this is not the case with Leksah []
  3. I installed some more plugins (thanks to people who commented on my previous post), so expect a follow-up []

Haskell IDEs, Part 1: Emacs

I’ve been working with Haskell for about 4 months now and I already have a bit of experience with three Haskell development environments: Emacs, EclipseFP and Leksah. I wanted to give an overview of these three, but this turned out to be a lot of writing so I decided to split this up into three separate posts, each describing one IDE. We’ll begin with Emacs.

Before I go into details of developing Haskell using Emacs let me write about Emacs itself. Emacs is a text-based (i.e. no GUI i.e. not WYSIWYG) text-editor for *nix systems. I stayed away from it for years, but when I started with Haskell and Lisp I realised that a lot of people regard Emacs as the best editor for these languages. I decided that it will be best to learn it and see for myself if it’s really that good.

Emacs has extremely steep learning curve. It is (un)famous for its keyboard shortcuts and I must say that this fame is well-deserved. First of all they are not intuitive for people that are used only to modern GUIs. Forget about Ctrl+C/Ctrl+V to copy-paste. Prepare to use C-w / C-y1 instead. That’s very subjective matter and after couple of weeks with Emacs these become quite intuitive. The more objective problem with shortcuts is the fact that they are overcomplicated and extremely hard to type. Unfortunately there’s a lot of examples: C-x C-s is required to save a file and nobody is going to convince me that this is better than simply C-s (this is one of the basic commands, you do it once every few minutes). Moving the cursor is even more insane: C-f / C-b to move it left and right (f denotes forward, b denotes backward), while C-p / C-n moves it to previous and next line respectively. OK, mnemonics are nice, but look where these keys are on the keyboard! That’s completely ridiculous, especially that most of us doesn’t care about mnemonics because we type without looking at the keyboard anyway. That said, editing code in Emacs can be faster than in graphical text editor. How come? Thanks to the keyboard shortcuts, but not because they are good, but simply because they exist. Graphical editors usually don’t have that many shortcuts and even if they do they discourage us from using them since everything can be selected from the menu. The problem is that using a mouse is slower than even the most crazy key combinations (my favourite is C-M-Space-u – that’s four keys at once). Still, Emacs could be a whole lot better if someone made a bold step to redesign its prehistoric shortcuts to something more ergonomic and adjusted to keyboards of today (Emacs shortcuts were designed with different keyboards in mind).

Another distinguishing feature of Emacs is the variety of different plugins (called ‘extensions’). They enhance the basic features of the editor with anything you can possibly imagine, including reading and sending email. There are two extensions that enhance Haskell editing in Emacs: Haskell mode and ghc-mod. Initially I used only the former one. It gives you nice code highlighting (IMO better than EclipseFP and Leksah), provides some basic code templates (guard insertion, where keyword and few more), possibility of starting a Haskell interpreter and interacting with it, e.g. executing code from the editor or automatic insertion of type annotations. However, I wasn’t able to get some of the features running. I’m not an Emacs hacker and I don’t have idea why they didn’t work out of the box, though I tried to change keyboard shortcuts of the non-working commands hoping that they will work.

Haskell mode offers great indentation management: it has four of possible ‘indentation policies’ and you can cycle between them using TAB key. This works great in practice. There are a few more neat features of Haskell-mode, like support for automatic unit testing or Hoogle integration, but I haven’t used them. Here’s a screenshot of Haskell code in Emacs with Haskell-mode enabled:

A nice thing in Emacs is that it doesn’t have any toolbars (except for the menu at the top, but it can be switched off), so when you set your terminal emulator to fullscreen mode you can see quite a lot of code at once. Another feature of Emacs that comes in handy is ability to align text according to a given regexp. This is very useful for aligning haddock comments – you can see an example on the screenshot.

After using Haskell-mode for a while I decided to give ghc-mod a try. These two extensions complement one another. Ghc-mod adds the possibility of code checking using either GHC or HLint, completing keywords, inserting code templates and inferred types of expressions. Unfortunately, most of the features of ghc-mod didn’t work OOTB and I couldn’t make them work. One of the features that unfortunately worked was code checking. It turned out to be a serious problem when I realised that the offending code is highlighted with some horrible background and this highlighting doesn’t disappear until the problem is fixed. Here’s an example:

Well, this was the end of my adventure with ghc-mod.

To sum up, Emacs offers nice syntax highlighting, very good indentation management and support for basic operations. The biggest downside might be an extremely steep learning curve. I enjoyed Emacs when I was learning the basics and working with only one file at a time, but when I started a small project that consisted of multiple files working in Emacs became a nightmare. Switching between multiple files turned out to be very annoying, though this is probably something you can get used to providing you have sufficiently strong will. I don’t, so I started looking for a full featured IDE. Occasionally you’ll hear hackers claiming that IDEs are completely unnecessary and Emacs combined with *nix shell will do just fine. Perhaps this is true for hackers and while I appreciate power of my Linux shell, I still prefer to have a dedicated development environment as most ordinary mortals do. The next post will cover one of them: EclipseFP.

  1. In Emacs convention C denotes Ctrl key, M denotes Alt key. C-w means pressing Ctrl and ‘w’ simultaneously, C-M-q means Ctrl+Alt+q. []

Staypressed theme by Themocracy