This is the first official pre-release announcement of JoinCabal.

It works like this:

$ joincabal

and creates this:

projectname/
projectname/LICENCE
projectname/ProjectName.hs
projectname/projectname.cabal
projectname/Setup.lhs

The important part is the dot-cabal file, since this is quite intricate and a bit dull to set up. It just outlines the basics of the program, what the executable will be called, who the maintainer is and their contact details, that kind of thing.

A previous version called mkcabal was written by Don Stewart. His is naturally more elegant than mine. JoinCabal — apart from being an obvious instance of NIH syndrome also writes a bit of licence header into the top of your main source file. Which is my justification for writing it.

And obviously it’s going to be grand and wonderful in the future. Obviously.

Optimus Prime may have been the greatest Transformer, but that’s not what I’m talking ‘bout here. I mean monadic transformers. And having spent some time reading about them and thinking about my next move in the Haskell programming… this is it.

What are monadic transformers? Well, most (let’s be fair: all) Haskell programs will make use of the IO monad to deal with the outside world. However there’s a number of other instances where monads can be useful — capturing errors, logging progress, maintaining internal state.

There exist separate monads in Standard Library for this stuff: Error and State, for example. But joining them together can be awkward even though many programs will have use for several of them at once.

One technique would be to build your own über-monad with all the bells and whistles you want. This would be both (a) daft, as the work is already done and (b) too error-prone.

The other technique is with monad transformers. They essentially provide an automated way to do monad nesting — such as IO (Either [String] [Bool]) — without all the tedious threading of monads. Kind of like a meta-monad, if you will, since you can sequence monads together in the way that monads allow you to sequence functions.

The other nice thing is that it cuts down on those horrible parentheses. Monad actions from different monads can be called back to back without causing a fuss. Example:

f = do a <- get                          -- from State monad
       liftIO $ print a                  -- from IO monad
       tell $ "found a " ++ show a       -- from Writer monad
       case a `mod` 2 of
           0 -> throwError "even number" -- from Error monad
           1 -> put $ a+2

I didn’t really understand them until I read the recent paper by Martin Grabmüller, Monad Transformers Step by Step. It’s still in draft at the moment but it’s very readable and dead useful.

You know yo’ve been doing far too much C(++) when you see a menu that says

Choose a burger and a pint* for only £3.99

and all you can think about is “pointer to a pint”.

Seen on LtU, in a discussion about closures in Java:

Also inner classes are the better and more 'java-way' to do closures

I can't see what makes them better, and if 'java-way' means anything then it must be a synonym with 'ugly' or 'verbose' or 'inconvenient'.

Miaow! Still, it's very true.

Java really is one of the ugliest languages around. I'm not sure what it is, but there's a singular lack of grace about nearly anything written in Java, and every way of doing things. Now, the world is full of ugly and inelegant code; Perl has made obfuscation-by-default into an art form and Visual Basic is never going to look like a real language no matter how much it grows up. But the inescapable fact of Java is that it seems to take the worst elements of syntax from all its influences.

Edit: In a fit of post-publishing research (the best kind, I'm sure you'll agree) I decided to check out Ada. I had a feeling that a language designed by and for the US military would not look pretty. And I was not disappointed. This "Hello, world" snippet is from the Wikipedia page:

with Ada.Text_IO; 

procedure Hello is
begin
   Ada.Text_IO.Put_Line("Hello, world!");
end Hello;

I have filed this post in the category called ‘geek’ for a very good reason. For (Haskell) functional programmers and fans of Iain M Banks, well, you’ll love it. The rest of you may be a bit confused but you can read it anyway for its silly comparison at the end.

You can find a proper explanation of the IO monad elsewhere. I won’t bore you with it here. Instead let’s talk about analogies.

The basic idea is this: monads are a container or context for carrying out some operations. The IO monad, for example, passes around an entity which we know as the Real World™. It enables pure functional languages to work properly as programming languages with input and output, without getting all mixed up. There are also other monads used besides IO, for processes that may not return a result (Maybe) or can return one of two different types (Either). And there is a whole separate universe in which all these different realities — these monads — operate independently of each other.

Really, the proper way to think about the IO monad is a smaller part of the whole. Instead we are used to thinking about the real world being everything there is, and changing our analogies to suit.

And what was that about Iain M Banks? Oh yeah. Well the Minds in his Culture novels work in pretty much the same way: the justification being that only a tiny proportion of their computational power and processes exist in the real world. The two or three metre long pods which represent these AIs in the books are just tiny protrusions into our world of vastly more sophisticated beings. If you’re not a fan of Iain M Banks, Douglas Adams talks about the very same thing with his mice — “three-dimensional representations of hyper-intelligent pan-dimensional beings” or something like that.

Most discussions of monads look at them as the functional programming world’s way of accessing the wider world. I prefer to think of them the other way round, as little sandboxes where functional programming is constrained by the real world.

Either way, the result is the same but sometimes changing the perspective you look at things can open up new insights. See, for example, the selfish gene and analysis of evolutionary theory from a genetic instead of an organism level.

This won’t be of much interest to many folk, but four of the original designers of the Haskell programming language are currently writing a paper on the history of the language. Drafts are available to read on the Haskell website, but for those less motivated I thought I would highlight the important section — how they chose the name:

[A] small but important moment in any language’s evolution is the moment it is named. At the Yale meeting we used the following process (suggested by Wadler) for choosing the name. Anyone could propose one or more names for the language, which were all written on a blackboard. At the end of this process, the following names appeared: Semla, Haskell, Vivaldi, Mozart, CFL (Common Functional Language), Funl 88, Semlor, Candle (Common Applicative Notation for Denoting Lambda Expressions), Fun, David, Nice, Light, ML Nouveau (or Miranda Nouveau, or LML Nouveau, or …), Mirabelle, Concord, LL, Slim, Meet, Leval, Curry, Frege, Peano, Ease, Portland, and Haskell B Curry. After considerable discussion about the various names, each person was then free to cross out a name that he disliked. When we were done, there was one name left.

That name was “Curry,” in honour of the mathematician and logician Haskell B. Curry, whose work had led, variously and indirectly, to our presence in that room. That night, two of us realised that we would be left with a lot of curry puns (aside from the spice, and the thought of currying favour, the one that truly horrified us was Tim Curry — TIM was Jon Fairbairn’s abstract machine, and Tim Curry was famous for playing the lead in the Rocky Horror Picture Show). So the next day, after some further discussion, we settled on “Haskell” as the name for the new language. Only later did we realise that this was too easily confused with Pascal or Hassle!