[Haskell-cafe] about Haskell code written to be "too smart"

[Loup Vaillant]

2009/3/26 Thomas Hartman <tphyahoo at gmail.com>:
>> Beginner list processing code can and often does go awry when presented with infinite lists.
>
> I didn't mean code that a beginner would write, I mean code that would
> be easy to understand for a beginner to read

For that, in this particular example, a type signature, would make the
function more than readable.

> -- that is, explicit
> pattern matching, explicit recursion, no gratuitous use of state
> monad.
>
> […]
>
> What I like about the pattern matching is the totality -- you see all
> the possible inputs, and you see what happens.

What I read here is "make the operational semantics more explicit". Do
you mean it? Personally, I see explicit operational semantics as a
last resort, not as a facilitator. Most of the time, I care about what
*is*, not what happens. Pattern matching (compared to function
composition) is not easier for beginners. It is easier for seasoned
imperative programmers, because otherwise, they have to reformat their
brain. In my opinion.

Now imagine you have to write your function as a solution to a math
assignment. Imagine that fold, map, zip, and the like are usual
functions (usual like sinus, exp, ln…). Of course, you have to prove
your solution correct.

Do you prefer a mere composition of four usual functions (possibly in
pointed notation), or do you prefer a recursive definition? Back in
high school, composition of functions (or nested formulaes) was easy.
Recursive definitions were the advanced stuff. If you want the utmost
confidence about the correctness of your function, I think you want to
reason about the function composition.



> With the state version, there's a lot of behind-the-scenes magic, and
> as we've seen, things can go wrong.

Well, about that, I cannot talk (I'm still a beginner).

Loup