On Haskell

[pozorvlak]

As I've mentioned a few times, I'm (re)-learning Haskell. Here are my current thoughts on the language. No doubt, when I have drunk of the Kool-aid in fullness, I shall look back on them and laugh/cringe at my naiveté. Please try not to get upset about them: if it helps, think of them as having big <at-my-current-state-of-knowledge> tags around them.

• Haskell's syntax is nice. Clear and concise. As part of my Haskell-learning regime, I've been going through Paul Graham's paean to the Lisp macro, On Lisp¹, re-writing the example code in Haskell. Thus far (ie, in the early, functional chapters), the Haskell code is generally shorter and clearer than the Lisp code it replaces, sometimes dramatically so. And recall that the Lisp code was written by an expert who's fanatical about brevity and writing for expositional purposes.
• In particular, pattern-matching is a Good Thing, as is the (+3) notation for operators. I note that Paul Graham wants to add something like the latter to Arc, in the form of [_ + 3], but of course you could implement it fairly trivially in Common Lisp with read-macros.
• On the other hand, Haskell's implementation of syntactic whitespace is needlessly complicated and unintuitive. Do you know the exact rules Python uses for syntactic whitespace? No, neither do I. That's because you don't have to.
• Pervasive lazy evaluation is a major win (but see also...). A lot of the On Lisp macro examples can be seen as workarounds for the lack of lazy evaluation.
• Pervasive partial application allows for some very nice effects, and could thus be construed as a win. However, it disallows optional and keyword arguments, prevents the existence of functions with the same name and different numbers of arguments, and in general rules out variadic functions (unless all the arguments are of the same type). All of these are Good Things. I haven't made up my mind which I'd rather have yet.
• Haskell's type system is not a major win. It may in fact be a win, but so far I have seen little evidence to support this. So far, it's caused me nothing but pain while writing code, and it prevents you from expressing lots of useful and well-defined ideas as Haskell code. Yes, it helped me find a bug the other day, but probably not as quickly as I could have found it in a weakly-typed language. It's less expressive than the type system Ada had in 1987 - in particular, the lack of types parametrised by integers is a huge sucking chest wound disfiguring the language. It's possible Data.Generic may help here - I haven't got my head around that yet.
  On the other hand, hackers whose opinions I respect assure me that some day I will come to see the type system as a friend and ally, so I'm trying to keep an open mind about this point in particular.
• On a similar note, type classes are an ugly crock.
• Haskell's documentation is inadequate. I've written about this before: then, I'd had a particularly Bad Documentation Day and was ranting, but I stand by the substance of my comments. It occurs to me that this may reflect a cultural difference. I come from Perl, which (intentionally) makes very few guarantees, and encourages the wide use of downloaded libraries. Some Perl libraries are well-known, but most are very specialised, and you might well download a library from CPAN for one specific project, hack with it for a day or two, and never use it again. In this environment, good documentation is extremely important, and thus community standards for docs are very high. Occasionally, they're even satisfied :-)
• Debugging tools are not luxury items, guys. I had a useful chat with Duncan over the weekend, and now intend to check out Buddha and Hat, but really, this stuff should come with the distribution.
• Hugs and GHCi are the two least useful toplevels I've ever had the misfortune to use.
• Referential transparency is a Seriously Good Thing, but then I thought that anyway. I'm not entirely convinced that the language should be enforcing it: it's often possible to write a side-effect free function that works by manipulating some state. Compiler optimisations, I suppose, and it's good to have "Here Be Dragons" signs around the non-transparent bits, in the form of the rather ugly monad syntax.
• I miss variable interpolation. I tried to add it using Template Haskell, but ran into some problems: I'll post about that some time. I also miss having hashes² at my fingertips. They're wonderfully useful things, and having them on a par with lists allows for some extremely cool/simple solutions to some problems. Syntax is not trivial.

By the way, I've fixed the juggling program. But then I was reading Burkard Polster's The Mathematics of Juggling on Saturday, and came across a much simpler algorithm: a siteswap [a_0,...,a_n-1] is juggleable iff the function (i |-> i + a_i mod n) is a permutation of [0..n-1] (by finiteness, iff it's a surjection). In Haskell (untested),

isJuggleable ss = and (map (`elem` test) [0 .. n])
        where test = map (`mod` n) $ zipWith (+) [0 .. n-1] ss
              n    = length ss

Or in Perl:

sub is_juggleable {
        $hit{$_ + $i++ % ($#_+1)}++ foreach @_;
        return scalar(keys %hit) > $#_;
}

See what I mean about the hashes? :-) Tests: er, that has a bug in it, but my girlfriend has been wanting to go home for a while now. I'll fix it tomorrow.

¹I strongly recommend this exercise to everyone, actually - writing code helps you to absorb the ideas, and thinking about why the code's different in the two languages helps you to see the tradeoffs between their design decisions. And On Lisp is a great book, with rather more than its fair share of Keanu moments - those moments when you sit back and say "Whoa." The chapter on anaphoric macros is particularly cool.
²By "hashes", I mean associative arrays/dictionaries/etc, I'm not bothered about the implementation. Data.Map qualifies, but it's a lot less convenient than just being able to say $foo{$bar} = $fred, or $foo{bar} = $fred (barewords are treated as strings in hash indexes). Consider how ugly most Haskell code would be if there were no syntactic sugar for lists...

Comments

[wormwood-pearl.livejournal.com]

Woo! Yay! First comment! I'm so cool. Do I get a prize?

[totherme.livejournal.com]

On learning to love the type system:

Something just occurred to me, which should have been obvious, and may in fact have been obvious to everyone but me. On the off-chance that it wasn't, I'll relate it here.

Just as you can't get the benefits of functional programming by doing procedural programming in ML (in fact, you'll just get annoyed by the way you keep having to fight the language to make the programme do what you want), I suspect you can't get the real benefits of static type checking just by running the type checker over code that you wrote as if it were dynamic. All it will ever do in that case is tell you what you can't do. If you're lucky, it might find a bug a bit faster than if you'd had to test for it.

The flip side of those things that you can't do, are the things you don't have to do. The type checker doesn't just provide rules, it provides guarantees. There are certain things that dynamic programmers have to think about, which static programmers do not - because the type checker does it for them. If a dynamic programmer codes in a static language, there's nothing to prevent him from continuing to duplicate the work of the type checker in his head, but if he does this, he doesn't feel the full benefit of having it there. This, then, is an argument that static typing is good, because it frees your mind from mundane things that the machine can think about for you - so that you can concentrate on more interesting higher level problems.

It's quite difficult to explain how to let go of the thoughts you don't need when the machine is watching your back - it's actually quite hard even to explain precisely which ones they are. I suspect I could give you examples if I spent a lot of time thinking about it, but I don't think they'd be very illustrative, and I suspect there's a short-cut we can use instead.

(ok, this next bit is potentially really condescending - it's not intended to be. I know that anyone reading this already knows how to program, and it looks like I'm trying to teach "how to program". What I actually want to do is describe a mindset that I suspect leans towards static typing - and the best way I know how to do that is by teaching novices how to code with it from scratch. I ask your indulgence in looking for that mindset in the following, rather than the face value "this is how to code".)

When we teach programming (particularly in haskell) to first year CS students, we always tell them to start with the type:

"Write a function sentances :: -> String -> [String] that takes a String, and returns a list of 'sentance' strings where each sentance begins with a capital letter, ends in a full stop, and contains precisely one full stop"

pozorvlak : I know that you were never a first year CS student - you skipped that bit, and went straight on to writing Hard Code ;) ...so I figure there's a chance that you were never encouraged to adopt this mindset. If you do want to see the type system from the (loving, awed) point of view of Duncan or myself, and if this isn't something you've tried already, then this might be a useful exercise to try:

Spend some time (a day, week, month, whatever) deliberately, and slavishly writing down the type of any code (in any language) that you want to think about. Do this before thinking about how the code behaves, or what it does. The process for discovering code to do what you want should hopefully become something vaguely like:

• What is the type of the input?


• What is the type of the output?


• (write them down)


• What are the properties of the input and output?


• What is the relationship between data with these input properties, and data with these output properties?

This is the logical conclusion of the school of thought that teaches "Get your data structures right first, and the algorithm will naturally follow" - applied everywhere.

To put it another way: The type of your code is a specification, not a side effect. Specify first, then implement.

(max comment length)

[sable-veins.livejournal.com]

Ha! "$hit" and "%hit" both look a bit like... shit!