2009/3/26 Thomas Hartman <tphya...@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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe