Hacker News Reader

Comment by rowanG077 | Hacker News Reader

You misunderstand my problem. Add a logger to that fibonacci function. Potentially EVERY usage site now has to change, maybe even multiple layers. Adding a log in most languages is a local transformation. In Haskell it isn't, it can have codebase wide consequences.

View on HN

That's because most languages allow arbitrary IO in all functions. You can achieve this in Haskell too if you want, by just using IO as your monad everywhere.

But most people don't do that because then it becomes really hard to reason about your code, so spending the extra time propagating a MonadLog constraint up your stack is actually worth it.

If you wanted to log from fibonacci, you would pass a some logger instance down to this function. In Haskell, this could be a record or a typeclass instance. In other languages, it could be an object or a struct. There is no fundamental difference. All the layers above would still have to pass this through; explicitly or implicitly.

The difference is most language have global state. See rust for example. It's not common to inject a logger, a "world" object for IO or anything for which you need monads in Haskell at all.

You are arguing from a concrete technical standpoint: "But you need to do the same thing in other language if you want to mirror Haskell monads". Sure, you are right. That also completely glosses over the point I'm making. I simply feel like the way haskell does it is unergonomic, it would also be unergonomic to something equivalent in other languages.

I don't know what a good solution would be, maybe a constrained partial type signature? Let the compiler pick the smallest constraint from a larger space of available constraints that fits with the usage and simply let the type checker bubble it up until you actually care to specify it? GHC doesn't support this but it should be possible in theory.

Does every usage site have to change? You would alter fibonacci to be:

  fibonacci :: (MonadLogger m, MonadState (Int, Int, Int) m) => m Int
  fibonacci ...

and now of course all callers must support MonadLogger. But instead of using the MonadLogger (or any mtl constraint directly) you should just be constructing an abstraction boundary with a type class synonym:

  class (MonadLogger m, MonadState s m) => MyMonads s m

and now you change fibonacci:

  fibonacci :: MyMonads (Int, Int, Int) m => m Int
  fibonacci ...

And now if you need to add a monad or add Eq or whatever you just have to change your type class synonym rather than every function. Its not a problem with the language its just programing with modularity in mind, even in the type system.

I have seen this in the wild. The result often is that every function has a kitchen sink MyMonads constraint of which it only uses a tiny subset. It's death by a thousand cuts. If you make such a class for every monad combination you get insanely large amount of classes. It's simply unworkable. Which is why you get the kitchen sink monad pattern.

And what's wrong with the kitchen sink monad pattern? I've certainly used exactly that. And I have no problems with it.

Because your code is very much overconstrained at that point. For the same reason you don't add a `Num a` constraint to list `head` function. You have now essentially fused your function to your codebase.

That's not a problem in business logic heavy code. Requirements change and you could use previously unnecessary constraints at any time.

If you think it's fine that you can log from all functions in other languages, then what's the problem with adding that constraint to all your Haskell functions to allow this?

The problem is that you should always write your code to be idiomatic in the language. In this case I feel like the Idiomatic Haskell way has serious drawbacks.

For example, It's fine in C to manually allocate/free memory, it's the way you have to write C. It's not fine to do the same thing in Rust. Even though you of course could do that in Rust as well.

It's perfectly idiomatic Haskell to annotate all your functions with an effect you believe they should all have.

The only reason this is idiomatic is because there is no better way. That's the entire point I'm making... Haskell prides itself in writing generic and reusable functions. This then is then thrown out of the window with the kitchen sink monad. Very understandable, because everything else sucks.

That precisely why I think this is a great shortcoming of the language.

It's not a shortcoming of the language; it's a shortcoming of the goal! You can't have both the goal of fine-grained effect tracking and the goal of not having to make fine-grained changes when effects change. They're incompatible goals in any language.

The strength of Haskell is that it allows you to achieve the first goal if you want. Most languages don't (pretty much no other language, actually).

That's an extremely limited point of view. Just because Haskell allows precise specification does not mean it is impossible to disallow loose specification. In fact that's one of the strongest values of Haskell's type system. For example you can overconstrain your head function

    head :: [Int] -> Int

But you can also just leave out the type signature all together to let the type checker figure out the most generic type. You can have your cake and eat it too.

You can even almost do what I want with partial type signatures. Just sprinkle it everywhere inside your constraints. GHC will automatically pick the right constraints. At the call site you actually care for the definition you can not use the partial type signature. The great disadvantage of this is that you now introduce ANY constraints into your type signature and you lose your types as documentation.

But that doesn't have to be

You could have a constraint with something like `UseMonadSubset (...)` which works almost like partial type signature. GHC should infer 0 or more of the monads insde `UseMonadSubset` as the actuall constraint. `

Then you could write something like:

    fibonacci :: UseMyMonadSubset m => m Int
    fibonacci = -- Uses only MonadState (Int, Int, Int)

    -- Type checks because type checker can see fibonacci ONLY uses MonadState
    foo :: MonadState (Int, Int, Int) m => Int
    foo = fibonacci

    bar :: UseMonadSubset m => Int
    bar = fibonacci

Which allows for precise specification if you want to and if you don't you let the type checker figure it out. You may even be able to implement this as GHC type checker plugin.

It's an interesting idea but I can't say I feel that would solve a problem I've ever had. In fact, I always completely annotate top-level definitions with their types. I never want them inferred. And I've never felt it too burdensome to fix up a call stack when adding a new effect. But if you consider that a weakness of Haskell then so be it!

Debug.Trace has a lots of stuff for that. You can even generate charts from that when using eventlog-enabled runtime.

If you just want to add logging to existing operations, reinterpret them at the call site. Something like this

    newtype LoggedStateT s m a = LoggedStateT (WriterT s (StateT s m) a) 

    instance (Monoid s, Monad m) => MonadState s (LoggedStateT s m) where
        get = LoggedStateT $ do
            val <- lift get
            tell val
            return val
        put s = LoggedStateT $ tell s >> lift (put s)

(which is basically an ad hoc effect system)

If on the other hand you want to reproduce the behavior of other languages, throw everything in `MyAppMonad` give it whatever capabilities you need.

Which requires sweeping changes... In most other languages it's literally a one liner where you want to log something.

It requires changing the places where you instantiate your monad transformer stack, which you should have very few of.

I don't think having very few is a good scenario. I have written a compiler and had about 10 different stacks. Changing every single one just to be able to add a logger to a single function somewhere is honestly insane.

What I see in the wild is having one huge kitchen sink stack which sucks as well.

Reply on news.ycombinator.com