3 ms·
Adding the Free monad to this approach doesn't add any cost in understandability?
by zak_mc_kracken 11y ago
Adding the Free monad to this approach doesn't add any cost in understandability?
- chowells 11y agoNot in a language with decent abstraction capabilities. You end up changing code from looking like: myThing :: Foo -> ProblemDomain Bar myThing f = do x <- subthing1 f y <- subthing2 x 23 return $ g y to looking like myThing :: Foo -> ProblemDomain Bar myThing f = do x <- subthing1 f y <- subthing2 x 23 return $ g y There's no difference, don't spend too much time looking for one. The underlying representations of the type change. How you interact with the type does not. There's no mental overhead. There is a small bit of added run time cost. You pay somewhere for adding the ability to interact with the type in additional ways, but not by breaking any existing code.
- zak_mc_kracken 11y ago> Not in a language with decent abstraction capabilities. My question has nothing to do with the language. You are adding a relatively advanced construct which requires a lot of prior knowledge to understand: Free monad, monad, applicative functor, functor, monoid. Then you need to understand the laws that monads must obey, which are not enforced by the type system. Before you get there, a passing grasp with Haskell and higher kinded types will help, and some basics in category theory too. Saying that adding the free monad doesn't have any cost in understanding is very naïve. You forgot how long it took you to reach that understanding.