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

[Thomas Hartman]

> 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 -- that is, explicit
pattern matching, explicit recursion, no gratuitous use of state
monad.

I don't think I necessarily would have written my favored version when
learning haskell, probably something a lot uglier.

What I like about the pattern matching is the totality -- you see all
the possible inputs, and you see what happens.

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

Also, the issue isn't infinite lists, but lists that are longer than
the sum of the partitions provided. The state monad partition version
goes equally as badly awry if the test is restructured as

testP pf = mapM_ putStrLn  [
          show . pf ( take 1000 [3,7..] ) $ [1..10]
          , show . pf [3,7,11,15] $ ( take (10^6) [1..])
          , show . head . last $ pf (take 1000 $ [3,3..]) [1..10^6]
        ]

(no infinite lists, just long lists)



2009/3/25 Dan Piponi <dpiponi at gmail.com>:
> On Wed, Mar 25, 2009 at 12:44 PM, Thomas Hartman <tphyahoo at gmail.com> wrote:
>>> Are you saying there's a problem with this implementation? It's the
>>
>> Yes, there is actually a problem with this implementation.
>
>> However, there is something to be said for code that just looks like a
>> duck and quacks like a duck. It's less likely to surprise you.
>
> Well the problem here isn't that the code does something surprising.
> It's author was making assumptions about the type of input that it's
> going to get. I think that's an orthogonal issue.
>
>> So... I insist... Easy for a beginner to read == better!
>
> Not at all. Beginner list processing code can and often does go awry
> when presented with infinite lists.
>
> The moral here has nothing to do with readability by beginners. It's:
> if the function you're defining could be extended naturally to
> infinite lists, and it would be useful to do so, then make it do so.
> --
> Dan
>