7 ms·

Thanks, I really appreciate your responses. What's to stop you passing a struct or object with the two monadic functions attached, or ignore the function requi

by sago 11y ago

Thanks, I really appreciate your responses. What's to stop you passing a struct or object with the two monadic functions attached, or ignore the function requirement (for the case of state) and pass the struct with the state and result in it? The benefit being that you can package up more than just one value in that (immutable) structure along with the 'specialness'. I don't see why that is less typesafe.

thinkpad20 11y ago
I'm having a tough time trying to understand what you're proposing. First of all, in Haskell there's no real concept of having functions "attached" to objects (in the OO sense). The closest analogue is a type class, which relates a type to a set of functions. For monad, that looks like class Monad m where return :: a -> m a (>>=) :: m a -> (a -> m b) -> m b And it's up to the particular instance to determine how those functions are implemented. For example, instance Monad Maybe where return :: a -> Maybe a return x = Just x (>>=) :: Maybe a -> (a -> Maybe b) -> Maybe b maybe >>= f = case maybe of Nothing -> Nothing Just x -> f x The definition of the State type, and its corresponding Monad instance, is a little more involved (I suggest this blog post for an explanation [1]): newtype State s a = State { runState :: s -> (a, s) } instance Monad (State a) where return x = State $ \s -> (x, s) m >>= k = State $ \s -> let (a, s') = runState m s in runState (k a) s' I'm honestly not quite sure what you mean by the rest of it (for example, "ignoring the function requirement", "specialness" etc). But the bottom line is that you can do any typesafe thing you want to, within the rules of how the language works. [1]: http://brandon.si/code/the-state-monad-a-tutorial-for-the-confused/ http://brandon.si/code/the-state-monad-a-tutorial-for-the-co...
- sago 11y ago
  Thanks again. Sorry, I wasn't talking about Haskell. Following the OP I was talking about the merits of using these concepts or structures in other languages (C++, as per the OP, in particular). Of course, in a language with strong support and syntax for a particular pattern, you should rely on that pattern. But beyond that, it can be useful to use a pattern in other languages. Carmack is talking about writing C++ in a more functional style. I've written OO plain C, for example, when that pattern has made sense, and much of my C++ is heavily influenced by my experience with Scheme. My point was that I don't get the emphasis on Monads, as a concept, for the range of things it gets emphasised for. In a language which has core syntactic and semantic support, and there are few alternatives, then of course it has to be used widely. But that's a different argument to saying it is an intrinsically good solution for those cases. I might be missing something, but as an architectural pattern in general it doesn't seem appealing. Not enough to reimplement in another language. That's the context to my comment on typesafety. You said that other languages aren't typesafe enough. I was suggesting that, implementing a monad as a structure or an object would be typesafe, so I couldn't see what was insufficient.

by sago 11y ago

thinkpad20 11y ago

I'm having a tough time trying to understand what you're proposing. First of all, in Haskell there's no real concept of having functions "attached" to objects (in the OO sense). The closest analogue is a type class, which relates a type to a set of functions. For monad, that looks like class Monad m where return :: a -> m a (>>=) :: m a -> (a -> m b) -> m b And it's up to the particular instance to determine how those functions are implemented. For example, instance Monad Maybe where return :: a -> Maybe a return x = Just x (>>=) :: Maybe a -> (a -> Maybe b) -> Maybe b maybe >>= f = case maybe of Nothing -> Nothing Just x -> f x The definition of the State type, and its corresponding Monad instance, is a little more involved (I suggest this blog post for an explanation [1]): newtype State s a = State { runState :: s -> (a, s) } instance Monad (State a) where return x = State $ \s -> (x, s) m >>= k = State $ \s -> let (a, s') = runState m s in runState (k a) s' I'm honestly not quite sure what you mean by the rest of it (for example, "ignoring the function requirement", "specialness" etc). But the bottom line is that you can do any typesafe thing you want to, within the rules of how the language works. [1]: http://brandon.si/code/the-state-monad-a-tutorial-for-the-confused/ http://brandon.si/code/the-state-monad-a-tutorial-for-the-co...

sago 11y ago
Thanks again. Sorry, I wasn't talking about Haskell. Following the OP I was talking about the merits of using these concepts or structures in other languages (C++, as per the OP, in particular). Of course, in a language with strong support and syntax for a particular pattern, you should rely on that pattern. But beyond that, it can be useful to use a pattern in other languages. Carmack is talking about writing C++ in a more functional style. I've written OO plain C, for example, when that pattern has made sense, and much of my C++ is heavily influenced by my experience with Scheme. My point was that I don't get the emphasis on Monads, as a concept, for the range of things it gets emphasised for. In a language which has core syntactic and semantic support, and there are few alternatives, then of course it has to be used widely. But that's a different argument to saying it is an intrinsically good solution for those cases. I might be missing something, but as an architectural pattern in general it doesn't seem appealing. Not enough to reimplement in another language. That's the context to my comment on typesafety. You said that other languages aren't typesafe enough. I was suggesting that, implementing a monad as a structure or an object would be typesafe, so I couldn't see what was insufficient.