Of course... I think many would say that your savings in resources came at the expense of readability. Basically, I think this falls dangerously close to Duff's device in the argument space of currying.

Your first point is fair. Of course, 'readability' is extremely subjective. It should always be judged in terms of the intended audience for the code - we'd have to ask a Haskell programmer to be sure.

Your second point I disagree with completely. Duff's device is non-idiomatic C that relies on oddities of C syntax (fall-through of cases in a switch statement, and the ability to jump into the middle of a loop). My code is reasonably idiomatic Haskell.

Apologies, I should have made the second point more on the humor side than not.

I should also stress that I don't think this being somewhat difficult to read is really bad. Just saying that I would expect a lot of folks to balk at it.

I'm guessing that you don't find this code readable because of the $ operator. Admittedly, if you aren't used to it, it does look weird; however, once you are used to it--and it doesn't take too long--it makes the code readable.

In particular, it naturally splits apart the different function calls. So you can look at the parts separately: L.intercalate "\n", cut (b'-b+1), map toChar, elems arr. Now you have a nice little pipeline.

Perhaps to somebody without Haskell experience, the version with parentheses would be easier to understand:

    L.intercalate "\n" (cut (b'-b+1) (map toChar (elems arr)))

However, in general, I find the $ version easier to follow.

I also think that this version is better than the same code broken up into arbitrary temporary variables. The pipeline is short and clear; adding temporary bindings would just give me more things to keep in my mind at the same time.

One way to think about this is that the $ is very similar to the | in bash, just backwards. So in a bash-like pseudocode, this is something like:

    elems arr | map toChar | cut (b' - b+1) | L.intercalate "\n"

Hopefully that clarifies the structure of the code and why that structure is actually very reasonable.

Basically, my point is that the given code is clear and simple; chances are you find it hard to read because Haskell is somewhat foreign and not because the given code is particularly complicated or obfuscated. In fact, I think this way of writing the code is clearer than what you would get in most other languages because it forms a very clear sequence of transformations on the input.

My main point is simply that most of the folks that do not see the benefit of currying, are not likely to be swayed by this. I muddied that by bringing up Duff's device.

I suppose that's fair. The core problem is that the benefits of currying depend to some degree on having amenable syntax, and this means that all the examples are going to seem foreign to people.

This same thought is made ridiculously clear when you try and use closure like structures in java. Especially if you have folks insisting on the @Override nonsense. Compared to languages that make full use of them, where you have to try and look for them to spot them. (Closures, that is.)