25 October 2006

Exploring Haskell

Having gotten somewhat stalled on learning more advanced Scheme programming paradigms, I have decided to try learning Haskell. In particular, I want to use Haskell to get both more lazy and more functional. It is all too easy for me to write Scheme programs which use recursion and lists but are basically translations of the way I would write things in Pascal. I can build my little closures, and do maps and folds, but the programs still evaluate everything, still compute everything, and still use a lot of mutation. My Scheme functions often aren't referentially transparent; they're often really methods to mutate objects.

It is reasonably legitimate to use Scheme that way, but I'm not learning much.

In particular I'd love to use something more advanced for my embedded work, but it seems to me that using Scheme is just going to turn compile-time errors into run-time errors, with its lack of typing, and although my programs might be shorter, they won't really be any more explicit.

In particular, although I have become reasonably facile with s-expressions and tend to be able to see "past" the parentheses, Haskell confirms my belief that it isn't actually necessary for the programmer to play compiler and write the abstract syntax tree him or herself. There's a little bit of buzz beginning about how Haskell is easier for beginners, and my experience with Dylan leads me to believe that typing is actually valuable; in Dylan, for example, it can make a difference between code that uses full runtime dispatch and takes twenty minutes to run, or a version that takes a few seconds.

I'd also like to better understand the lazy paradigm, where a very large or infinite list or tree does not have to be fully generated or fully evaluated in order to be useful. I'd like to understand Monads, or at least how to use them.

A lot of my programming work involves explicit or implicit state machines and plumbing to manage state changes. To improve this I really just need something a lot more concise and expressive than C++. I need leverage, not totally new programming paradigms, at least not at first. So we'll see if Haskell can help me there.

I've been faintly interested in learning languages like Clean, or ML, or Miranda, or Ocaml. But so far what I'm reading leads me to think that it may not be worth my time to bother with these and that Haskell has absorbed a lot of the things that are cool about these languages and may, in fact, be the shit. A large amount of material is being written about Haskell, and the stable base/experimental extensions approach seems like the right thing. In other words, Haskell seems like a language upon which a lot of smart people are converging.

And if it isn't, maybe I can take some of what I learned using it back to Scheme, or maybe Kernel.

More to come!

2 comments:

Miles said...

[Er, sorry, clicked "Publish" too soon on the last attempt]

[M]y experience with Dylan leads me to believe that typing is actually valuable; in Dylan, for example, it can make a difference between code that uses full runtime dispatch and takes twenty minutes to run, or a version that takes a few seconds.

Wow. I'm coming to Haskell from Perl, and I'm finding the type system a rich source of pain and frustration, so this really caught my eye. Could you post the relevant code?

Paul R. Potts said...

Hi Miles,

I was just intending to point out a case where a dynamic language performed a lot better when types are provided so that generic dispatch does not have to occur and the compiler can generate more straightforward code. The code in question was a toy implementation of the old standby problem, the Knight's Tour. I could send it to you -- I was building it with d2c. There were some specific issues with d2c where it would not generate efficient code unless you introduced typed intermediate variables. They may have been fixed by now, or may perform better in OpenDylan (using the old Harlequin code base).