On: Return type polymorphism in Haskell

[marcosdumay]

Can you see how that small change on the interface makes it awful to write code that is generic on Monoid?

It does not fit the requirements. It makes the kind of code people write in Haskell absolutely not viable.

[louthy → marcosdumay]

Why don't you deal with specifics? I am not talking about its attractiveness, I have already made clear that I think Haskell is more elegant. But, why is this "not viable" or "does not fit the requirements"? I have already shown how a totally generic version of mconcat can be implemented - so how is this not writing "code that is generic on Monoid"?

[marcosdumay → louthy]

One very specific. I create a logging module on Haskell. There I put some high order functions like this:

    module Log where

        -- | Runs the code inside a catch, logs any exception
        exceptions :: IO a -> IO a
        
        -- | Logs every code execution
        access :: IO a -> IO a

        -- And so on, for several different kinds of logging

Then on the main code I do:

    import qualified Log as Log

    main = do
        -- Lots of stuff
        Log.errors . Log.access $ readSomeData
        Log.errors $ whateverThatCanFail
        Log.access $ shoudlntFailButICareAboutRunning

On C# each use of those logging functions will be more verbose than copying the entire function body in place. And almost as brittle.

[louthy → marcosdumay]

Sorry, where did I say C# is less verbose than Haskell? And what has that got to do with implementing polymorphic return values?