Forgot your password?
typodupeerror
Programming IT Technology

Why Lazy Functional Programming Languages Rule 439

Posted by ScuttleMonkey
from the laziness-is-the-mother-of-all-invention dept.
Da Massive writes "Techworld has an in-depth chat with Simon Peyton-Jones about the development of Haskell and his philosophy of do one thing, and do it well. Peyton-Jones describes his interest in lazy functional programming languages, and chats about their increasing relevance in a world with rapidly increasing multi-core CPUs and clusters. 'I think Haskell is increasingly well placed for this multi-core stuff, as I think people are increasingly going to look to languages like Haskell and say 'oh, that's where we can get some good ideas at least', whether or not it's the actual language or concrete syntax that they adopt.'"
This discussion has been archived. No new comments can be posted.

Why Lazy Functional Programming Languages Rule

Comments Filter:
  • by Anonymous Coward on Friday September 19, 2008 @11:21AM (#25071695)

    But I was too lazy to click on 13 pageviews.

  • Mmmm, Kay. (Score:4, Informative)

    by jellomizer (103300) on Friday September 19, 2008 @11:23AM (#25071731)

    Hascal, and other functional languages may be good for multi-core development. However not to many programmers program in them... Plus I find they do not scale well for larger application. Its good for true computing problem solving. But today most developopment is for larger application which doesn't necessarly solve problems per-say but create a tool that people can use.

    • Re:Mmmm, Kay. (Score:5, Insightful)

      by thermian (1267986) on Friday September 19, 2008 @11:35AM (#25071935)

      I spent a whole term at uni learning Miranda, which is similar to Haskell, I really liked it. I have *never* seen it being used since. To my mind they both belong in the category 'interesting, but pointless'.

      Its not just because they're old. If age was what killed languages, C and Lisp would be long dead. There just isn't anything I could do with either that I wouldn't be able to do more easily with another more 'mainstream' language.

      • Re:Mmmm, Kay. (Score:4, Interesting)

        by beelsebob (529313) on Friday September 19, 2008 @11:47AM (#25072121)

        I call FUD. There's a lot of things that Lazy functional languages make easy, that mainstream languages don't. Here's just a few examples:
        Infinite data structures can be handled naturally. Here's a function that generates the infinite list of fibbonacci numbers:
        fibs x y = x : (fibs y (x + y))
        Here's a list that does a complex calculation on every one of the fibbonacci numbers:
        map complexCalculation (fibs 1 1)
        While we're at it, Haskell programs are very easily parallelisable. Here's the same list, but computed on multiple cores:
        (parMap rnf) complexCalculation (fibs 1 1)
        Haskell only evaluates what it has to -- this program for example which looks up the 3000th element of the sequence will not compute the complexCalculation on the 2999 fibbonaccis before hand like a traditional program would:
        (parMap rnf) complexCalculation (fibs 1 1) !! 3000

        There's only a small sample of what's so powerful about these languages. If you'd bothered to RTFA, you'd know there are a lot more. But then, I guess this is slashdot.

        • Re:Mmmm, Kay. (Score:5, Insightful)

          by Dragonslicer (991472) on Friday September 19, 2008 @12:06PM (#25072417)

          I call FUD. There's a lot of things that Lazy functional languages make easy, that mainstream languages don't. Here's just a few examples: Infinite data structures can be handled naturally.

          Might that be because infinite data structures don't often exist in mainstream and/or commercial software applications?

          • Re:Mmmm, Kay. (Score:5, Insightful)

            by mean pun (717227) on Friday September 19, 2008 @12:14PM (#25072567)

            Might that be because infinite data structures don't often exist in mainstream and/or commercial software applications?

            Might that be because mainstream programming languages don't support infinite data structures?

          • by jbolden (176878)

            Sure they do. How many lines in the next web page? How many variables? How many on the whole site? How many simultaneous users? How many files do they need access to?

            Not having to worry about these constraints saves tons of time.

          • Re:Mmmm, Kay. (Score:5, Insightful)

            by david.given (6740) <dg AT cowlark DOT com> on Friday September 19, 2008 @12:36PM (#25072869) Homepage Journal

            Might that be because infinite data structures don't often exist in mainstream and/or commercial software applications?

            Sure they do. On my computer, there's an infinite stream of ethernet frames arriving, an infinite stream of video frames leaving, an infinite stream of keyboard events arriving, etc.

            The thing about functional languages, and strict lazy functional languages like Haskell, is that the underlying principles are quite different from procedural languages like C. In C, you tell the computer to do things. In Haskell, you tell the computer the relationships between things, and it figures out what to do all on its own.

            Personally, I suck at Haskell --- I'm too much of a procedural programmer. My mind's stuck in the rails of doing thing procedurally. But I'd very much like to learn it more, *because* it will teach me different ways of thinking about problems. If I can think of an ethernet router as a mapping between an input and output stream of packets rather than as a sequence of discrete events that get processed sequentially, then it may well encourage me to solve the problem in a some better way.

            • Re:Mmmm, Kay. (Score:4, Informative)

              by Dragonslicer (991472) on Friday September 19, 2008 @12:58PM (#25073213)

              On my computer, there's an infinite stream of ethernet frames arriving, an infinite stream of video frames leaving, an infinite stream of keyboard events arriving, etc.

              You keep on using that word. I do not think it means what you think it means.

        • Re:Mmmm, Kay. (Score:5, Insightful)

          by Bill, Shooter of Bul (629286) on Friday September 19, 2008 @12:09PM (#25072485) Journal
          I agree 100% Haskell is awesome. However, not everyone who is designing rails like sites is going to be working with fibbonacci numbers. We, the doers of awesome, must come up with real world solutions to real world problems that make use of the awesomeness. And then we must document the awesome for all to see and appreciate.
        • Re:Mmmm, Kay. (Score:5, Insightful)

          by Dhalka226 (559740) on Friday September 19, 2008 @12:15PM (#25072589)

          I call FUD.

          I call meme misuse.

          • by afabbro (33948)

            I call FUD.

            I call meme misuse.

            Thank you. There is no fear, uncertainty, or doubt here.

        • by Abcd1234 (188840)

          Mmmm... yes, I see you picked a few practical, real world examples, and didn't try to stack the deck with tasks that Haskell (or a similar language) would be particularly well-suited for.

          Or not.

        • Re:Mmmm, Kay. (Score:5, Insightful)

          by NoNeeeed (157503) <slash@nosPAm.paulleader.co.uk> on Friday September 19, 2008 @12:18PM (#25072623) Homepage

          Here's a function that generates the infinite list of fibbonacci numbers: fibs x y = x : (fibs y (x + y))

          You have just demonstrated thermian's point.

          How often do you actually need to generate infinite sequences? I have never needed to do that outside of a functional programming class.

          I'm a big fan of alternative programming languages, I've used some 20 or so since I started 20 years ago. I did a fair amount of commercial Prolog development after I left university, I really like Prolog. It makes certain things really easy and it's a joy to code certain types of solutions in, but I'm never going to write a web-app, or a word-processor in Prolog.

          Many of these languages are very clever when it comes to doing certain things, but how often do you actually need to do those things?

          The truth is that the vast majority of the software out there does pretty dull, mostly procedural jobs. That's why the main languages in use are just dull variations on the procedural, C/Java/Perl style. No matter how much maths geeks go on about functional programming, procedural systems will always be more suited and easier to use for most of the problems out there.

          That isn't to say there is no place for these alternative languages, but it's a smaller one which you probably won't see very often.

          Paul

          • by beelsebob (529313)

            How often do you actually need to generate infinite sequences?
            Actually, when you're able to do it naturally in your language, it becomes a very useful thing to do. For example, when you want fresh variables in a compiler, it's very useful to have the infinite list of variable names you haven't used yet hanging about.

        • Re:Mmmm, Kay. (Score:4, Insightful)

          by Rob Riggs (6418) on Friday September 19, 2008 @12:19PM (#25072633) Homepage Journal

          Functors and generators will do the same thing for you in a more mainstream languages like C++ and Python. And they'll be a hell of a lot more understandable to your average still-wet-behind-the-ears programmer. And you can certainly write code in those languages to do lazy evaluation.

          Now, I will grant you that, in general, one can do it more concisely in Haskell than one could in C++ and even Python. But these languages are more well rounded, IMO, than Haskell.

        • Features of Haskell I really enjoy are how it handles constructors, pattern-matched function arguments, user-definable infix operators (with configurable precedence!) and the way it handles higher-order programming and lazy programming. But I never got monads...

          Of course, my philosophy is that that's not necessarily a bad thing. Haskell is, IMO, a domain-specific language specialized on functional problems. I feel it's better to have different specialized languages working together well, rather than have

        • by localman (111171)

          That is very cool, but does anyone need to do any of those things in the programs that are being created and used today? I'm talking websites, media players, and video games? Haskell may be the coolest thing in the world but maybe not many people need or want the coolest thing in the world. This is always the problem with arguing "but it's better!": things generally only need to be good enough.

          If you don't believe me, look at the human race. Do you think that high intelligence or great beauty are driv

        • by Vexorian (959249)

          I call FUD

          Did you know that FUD does not really mean 'disagrees with what I think'? He never said lazy languages are useless, he mentioned LISP as a language that's still being used. In my opinion lazyness is useful, so let's just wait for an imperative language to steal that feature so people can actually use it, just like what happened with the rest of functional languages' features... (I know people are gonna mod me troll for this, don't worry)

        • Re:Mmmm, Kay. (Score:5, Insightful)

          by 0xABADC0DA (867955) on Friday September 19, 2008 @01:10PM (#25073445)

          Haskell only evaluates what it has to -- this program for example which looks up the 3000th element of the sequence will not compute the complexCalculation on the 2999 fibbonaccis before hand like a traditional program would

          And then when you actually do use the other values you program is ridiculously slow because the generator function is recalculating the fibonacci number over and over again.

          Except you hope that Haskell automatically memoizes the results, but that destroys your smp performance as the CPUs contend over the result cache. So maybe you have separate caches per thread. Then you program grows larger and all the memoization takes too much memory and the system start dropping out results (3000th fib is what 520? bytes). Then you have to go back and tell it to keep the results longer for that function.

          In the end maybe you just make it a list that's precomputed.

          But that's really beside the point, because you can do the exact same thing in Smalltalk, Ruby, JavaScript, etc, with most of the same costs and benefits. So really the question is, what makes it better than Smalltalk? It's faster at maths, but that's about it. But it has a harder/alien paradigm, the syntax is foreign, etc. Maybe that's why afaik mainly Haskell is only being used by people that crunch numbers ?

          • Re:Mmmm, Kay. (Score:4, Insightful)

            by mdmkolbe (944892) on Friday September 19, 2008 @04:57PM (#25077735)

            Except you hope that Haskell automatically memoizes the results

            Please don't take this the wrong way, but please stop spreading your misinformation. One doesn't hope Haskell memoizes because it doesn't memoize functions. One requires that Haskell implement call-by-need. Overlapping but very different concepts. I'll assume it was an honest mistake but the difference makes the rest of your post nonsense.

            Haskell is only being used by people that crunch numbers

            Another point of dissagrement. If anything number crunchers (e.g. scientific computing in which I've done a fair bit of work) avoid Haskell (along with anything that is not Fortran, Matlab or C). Haskell finds favor more among "programing language" types who are interesting in writing their own language (Haskell is a phenominal language to wrong another language in) or in "elegant" ways to write compact solutions to traditionally verbose problems (e.g. merge sort in two "statements").

        • Re:Mmmm, Kay. (Score:4, Insightful)

          by osgeek (239988) on Friday September 19, 2008 @04:54PM (#25077687) Homepage Journal

          paraphrase comment #1: Haskell is too academic to be useful.

          paraphrase comment #2: No it isn't, here's how to do something with a fibbonacci sequence.

          Uh, you failed at "fibbonacci" to make your point. :)

      • Just because a language is not widely used outside academia does not mean it isn't a good teaching tool. You can pick up a new language in a few weeks, but a strong understanding of the fundamentals lasts forever. In a teaching setting, you want a language and dev tools that do not get in the way of illustrating the concepts.

        At my university, a professor chose C++ to teach computational linguistics to non-programmers. HUGE mistake! We spent about 80% of the course learning C++ badly, rather than linguis

    • Plus I find they do not scale well for larger application.

      And you discovered that through your own experience with functional programming languages, did you? It's remarkable that you could have gained such insight, yet not know how to spell the name of one of the best-known FPLs in town.

      I rather suspect that, like many critics of FPLs, you have never actually tried to use them for a big project, and just assume that they won't scale because you read it somewhere.

      But today most developopment is for larger application which doesn't necessarly solve problems per-say but create a tool that people can use.

      I'll gloss over whether your unverified assertion about "most development" is actually true. Even assum

  • by m50d (797211) on Friday September 19, 2008 @11:29AM (#25071821) Homepage Journal
    The problem with Haskell is that it's a superb language for solving the sort of problems its designers foresaw. Unfortunately it makes it almost impossible to do things they didn't expect; you're too trapped in the rigours of the Haskell way of doing things.

    A separate, but related problem is that the community doesn't seem interested in practical use of it - there aren't lots of bindings to libraries to make easy things easy. Heck, even doing i/o at all isn't really supported very well. Functional programming is very good for the pure computer science part of programming, but unfortunately that's going to make up less than half of any given program. You also need to be able to interface.

    So I think the quote in the summary is right: people won't be adopting Haskell or similar pure-functional languages any time soon. What will happen is the next generation of dynamic languages will adopt the best features from functional programming; we've seen that happen already in python and ruby, and it'll happen again. And people will start using them there.

    • by beelsebob (529313) on Friday September 19, 2008 @11:36AM (#25071941)

      A separate, but related problem is that the community doesn't seem interested in practical use of it
      Really? That's why there's a new book called Real World Haskell [realworldhaskell.org]. The IRC channel on freenode is one of the largest on the entire network, and full of people doing real world things with haskell.

      there aren't lots of bindings to libraries to make easy things easy.

      I call FUD. The Hackage database [haskell.org]has literally hundreds of libraries sat there ready for you to use. And if you really need something that isn't there, the FFI is mature, and very easy to use.

      • by raddan (519638) on Friday September 19, 2008 @12:21PM (#25072663)
        I think the real problem with Haskell is that you're required to use your brain to make any use of it. I.e., you have to be one of those people who, upon opening a Knuth book, goes "Wow!" If you were a mediocre CS student, or you have no formal CS or mathematics training, Haskell is going to be very hard for you to wrap your head around.
        • by beelsebob (529313)

          I think the real problem with Haskell is that you're required to use your brain to make any use of it.
          What, you mean you can't just bash your head against a keyboard repeatedly and expect your program to compile (but not necessarily work? Call me irrational, but hey, I see that as a good thing! Making programmers think before they write something, and then having it work first time is great!

    • by sribe (304414) on Friday September 19, 2008 @11:39AM (#25071989)

      You also need to be able to interface.

      Which is exactly why I find Scala [scala-lang.org] to be interesting. Note: I haven't had time to learn or use it yet, but the design concept there is very interesting.

      • by burris (122191)

        I've been using Scala and it's the only way to do anything with Java, imho. Sure, it's no Haskell but it's pretty darn nice. A lot nicer than Java without the performance penalty of other languages that target the JVM, such as Groovy or Python.

        Even if you don't have to use Java, the popularity of the language combined with the pervasive NIH syndrome of the community means there is a very rich library of software components to use.

    • by Unending (1164935) on Friday September 19, 2008 @11:39AM (#25071997)

      Very true, I did a large project in Haskell for a CS class once the three of us working on it hated the language after we were done.
      Before that we were pretty happy with Haskell, because the programming assignments leading up to the final project were all fitted to the language, but the instant we had to do something that wasn't, we realized what a mess it is.

    • by Dan East (318230)

      Right in the middle of reading your comment I realized they must have changed something in the Matrix again.

    • by cameleon (149744)
      This is completely false. IO is well supported, with an almost imperative syntax. And as others have mentioned, there are hundreds of libraries available. As an aside, functional isn't the coolest aspect of Haskell. I think its type system is much cooler (although not as cool as Agda's).
      • Re: (Score:2, Interesting)

        by cylence (129937)

        This is only true for specific implementations. The Haskell 98 report only specifies library support for textual input/output, and is completely useless for portably handling Binary IO. That everyone just uses GHC anyway, which has great support for Binary IO, doesn't negate the point that Haskell itself sucks when it comes to IO.

        Other serious shortcomings would have to include lack of proper locale/encoding support (characters are read in as Unicode values; but what is the original encoding assumed to be,

    • people won't be adopting Haskell or similar pure-functional languages any time soon.

      Correct-a-mundo. On the Haskell part at least. Javascript is a functional language that has managed to go mainstream. Whether you would call it "pure" or not is open for debate.

    • Re: (Score:3, Interesting)

      by sergstesh (929586)
      And why not OCaml ? Nicely separated into both functional and imperative parts.

      Has a lot of lazy evaluation stuff in libraries.

      Has modifiable syntax/grammar.

      Very efficient - number 2 after "C".
    • And people will start using them there.

      Them there what ?

  • by Kingrames (858416) on Friday September 19, 2008 @11:33AM (#25071899)
    The picture in the linked article is missing a beard.
  • by OrangeTide (124937) on Friday September 19, 2008 @11:35AM (#25071927) Homepage Journal

    I haven't really been able to figure out how to do anything significant in Haskell. But I suspect that one day a language more like haskell and less like C will end up being the most popular. Monads and all that kind of confuses me.

    I think it helps if you have a strong math background and are comfortable with Lambda calculus. I'm just an old C hacker and haven't used any real math in like 10 years, so I'm not that effective in Haskell :(

    • by Nursie (632944)

      Personally I'm pretty happpy with pthreads and C anyway... I've yet to be sold on any of these new languages.

      • I can get things done in C, and it pays the bills. So I'm not complaining. But I think that letting the compiler figure out the threading for you will be the way of the future when something as simple as a cellphone consists of 300+ minimalistic processing cores working together.

        It seems unnecessary today to thread out for more than a dozen cores, but maybe some future technology will require a fair amount of processing power to operate. Perhaps holographic projection need it to encode/decode a data stream

    • by LWATCDR (28044) on Friday September 19, 2008 @11:47AM (#25072125) Homepage Journal

      Don't worry.
      In a few years you will see c++++ which will be c++ with functional programing tacked on. Of course you will also see Functional Object C but only Apple will use that.

      • by Shados (741919)

        Well, that C++0x thing or however its called has lambdas and functions closer to being a first class construct...so thats pretty much exactly whats happening already, give or take :)

        • by LWATCDR (28044)

          I should have learned this a long time ago.
          Don't try and make stuff up to be funny. The truth is silly enough without my help.
          All I can say is ewwwww..

      • C++'s template system is actually a Turing-complete functional programming language.

        -Chris

    • by Abcd1234 (188840)

      Monads and all that kind of confuses me.

      And that's exactly the problem. What are Monads? I'm not really sure (I sort of have a vague intuition of what they are, but that's it). But I do know that you need them in order to do anything that involves side-effects in the world outside of Haskell. And that includes I/O. Yes, that's right, you need to understand a rigorous mathematical construct in order to write a "Hello World" program. There's simply *no way in hell* a language like that will become popul

    • ...one day a language more like haskell and less like C will end up being the most popular.

      Welcome Perl. Read Higher-Order Perl ( http://hop.perl.plover.com/ [plover.com] ) if you don't believe me.

      Best of all, it's always installed on all unix boxes (including macs!)

      The only thing that's lacking is automatic palatalization across many cores for map{} operations, but I'm sure I can write a custom iterator to bucket things into N-threads on N-core CPUs if such a need arises.

    • I haven't really been able to figure out how to do anything significant in Haskell. But I suspect that one day a language more like haskell and less like C will end up being the most popular. Monads and all that kind of confuses me.I think it helps if you have a strong math background and are comfortable with Lambda calculus.

      Monads, lambda, calculs...arrr, matey, now I know why Haskell's such a bloody mess - Neal Stephenson wrote it! That be why it seems good at first and falls apart at the end.

  • This must be some use of the word "rule" that I was previously unaware of!
  • by fermion (181285) on Friday September 19, 2008 @12:11PM (#25072509) Homepage Journal
    At least since the late 70's, and certainly through the 80's, one of the best practices was functions that had limited scope and data knowledge. Of course this was codified into OO languages, but even in old style languages it was always bad to know too much or make too many assumptions about what was going on elsewhere.

    We can see this philosophy in C where, except where huge data structures are involved, it is best to make a copy of data rather than work to work on someone else's copy. Likewise functions do one thing, do it well, and, again except for huge data structures, return a copy. Memory is manually allocated, and deallocated, possibly from the functions local heap.

    It is interesting to me how it all comes back to just best practices. Make sure you know how much memory you need. Make sure you are only doing what needs to be done right now. Make sure the interfaces are clear. If data is ready, then it should be ok to work on it. To me functional programming is what happens after data models, or objects, are defined. Once the data structure is defined, you can treat it as stateless immutable input. Output is a another structure. Again, the only limitation is if the object is so large that duplicating become a cost performance issue.

    • We need a simple language - C
      This OO thing is nice - C++
      This Virtual machine thing is nice - C#
      Lazy Functional languages are nice - C@ ?

      If in doubt bolt it onto C ... ;-)

  • It figures that this article would be an interview. That way Simon Peyton-Jones didn't need to evaluate the answer to any question until it was asked.

  • by rolfwind (528248) on Friday September 19, 2008 @12:36PM (#25072873)

    What's the difference between a functional language like Lisp and a lazy functional language?

    Just asking.

    • Re: (Score:3, Interesting)

      by clampolo (1159617)

      Lazy evaluation means that a value won't be calculated until it is absolutely necessary. So in the example in the above discussion, you can make things like an array of all the Fibonacci numbers. This works because the environment won't actually calculate anything until it is necessary.

      Lisp doesn't support this behavior by default. In LISP all function arguments are evaluated left to right. Although using macros, you could probably write your own lazy evaluation mechanism.

    • by jd (1658)
      ...is the one with the newspaper over its face, snoring in the corner, cans of soda piled up on the desk. The functional language is the one that has finished psychotherapy, is fully alert and active, and has a far higher risk of suffering a heart attack from overwork.
    • by mdmkolbe (944892) on Friday September 19, 2008 @05:22PM (#25078207)

      In a lazy language (more properly called "call-by-need"), every expression has a thunk wrapped around it and thunks are automatically forced. (They have thunks in Lisp/Scheme but they must be explicit rather than implicit.)

      Lazy languages allow you to "use" values that haven't been defined yet. For example

      a = 1 : b
      b = 2 : a

      Which would produce two lists of alternating ones and twos (a starts with 1 and b starts with 2; also ":" is infix "cons").

      In Scheme (which I know better than Lisp), you could accomplish the same with

      (let ( [a (cons 1 #f)]
      [b (cons 2 #f)])
      (set-cdr! a b)
      (set-cdr! b a)
      ...)

      But being lazy (1) frees you from thinking about order of evaluation and (2) allows some constructs to be expressed more easily (e.g. taking the fixed point of a composition of functions (example to complicated to post here)).

      At the end of the day, any program written in one style can be written in the other so its all differences of ease and different ways of thinking about the program.

  • Oh my god! (Score:4, Funny)

    by Vexorian (959249) on Friday September 19, 2008 @12:39PM (#25072915)
    Could this be the year of Haskell in the developer's tool box?
  • by Tetsujin (103070) on Friday September 19, 2008 @12:46PM (#25072991) Homepage Journal

    One thing in Haskell that always intrigued me was the idea of combinatorial parsers - a parser that accepts a string and yields not a single parse tree, but all possible parse trees based on the language rules... Simple implementations of those can be implemented in Haskell pretty straightforwardly. Combinatorial parsers for individual rules are stuck together - and while rules may generate a bunch of possible parse trees these are culled by successive rules...

    I don't know too much about the practical efficiency of these - but in terms of how they're expressed I think they're great...

  • Transactional Memory (Score:3, Informative)

    by wirelessbuzzers (552513) on Friday September 19, 2008 @05:28PM (#25078341)

    Thoughts on Haskell, from a Haskell programmer.

    Haskell has a very nice software transactional memory [haskell.org] library, which makes a lot of otherwise-difficult concurrency problems much easier. It's statically safe, too, unlike similar libraries for imperative/OO languages.

    Certain other language features are very nice. Monads are also extremely powerful once you wrap your head around them, and the type-class system and standard libraries make a lot of math programming problems much easier.

    The language also has downsides. The laziness makes it possible to build up an arbitrarily long chain of suspended computations, which amounts to a hidden memory leak. Laziness also complicates the semantics for "unchecked" exceptions, most notably division by zero. The combination of laziness and purity can make the language very difficult to debug and optimize. While the compiler has very powerful optimization capabilities, sometimes code needs to be just so to use them (like flagging things "const" or "restrict" in C), and this can make it hard to write clean code that runs fast.

    The other problem is that most programs need some amount of imperative code somewhere to do the I/O. This code has a tendency to be verbose, nasty and slow in Haskell.

    There are also some problems that would be relatively easy to solve in a very nice way within the semantics of the language (give or take), but are not solved well in the standard libraries. These include exception handling, global mutable state, strings and regular expressions, certain I/O operations, arrays and references. It would be very nice if the ST and IO monads were unified, and if references and arrays had nice syntax; this would reduce the ugliness needed to write those occasional bits of imperative code.

No skis take rocks like rental skis!

Working...