5 ms·
> Because, that's nowhere near general enough to describe what monads can do Totally disagree. You are effectively saying you cant define anything unless you i
by supermatt 3y ago
> Because, that's nowhere near general enough to describe what monads can do
Totally disagree. You are effectively saying you cant define anything unless you include every case, which is clearly nonsense.
> it's not obvious from looking at the definition of a monad that it allows us to do sequential IO
The transform is "transform the wrapped properties into some IO call", and all transforms are explicitly sequential.
- bowsamic 3y ago> You are effectively saying you cant define anything unless you include every case, which is clearly nonsense. No I'm not. I will repeat what I said again: such things are defined by their general mathematical definition, and any analogy can only speak for certain subsets of examples of that definition. > The transform is "transform the wrapped properties into some IO call", and all transforms are explicitly sequential. How exactly does the mathematical definition of a monad say anything about "transforms"? I think you didn't actually read my comment.
- supermatt 3y ago> How exactly does the mathematical definition of a monad say anything about "transforms"? Im not sure that it does, but a "transform" as I mean it in my basic description is applying an operation to the "wrapped" properties.
- bowsamic 3y agoThe transformation mentioned there has nothing to do with using the bind operator within a monad. An example of a natural transformation would be transforming from one monad to another monad
- uxp8u61q 3y agoThe word "transformation" in that name has absolutely nothing to do with your use of the word "transform" ("transform the wrapped properties into some IO call"). MacLane could have decide to call natural transformations "widgets". My point is, besides the name (which is completely arbitrary), why would you even begin to believe this has something to do with "transforming properties into IO calls"? Nice shadow edit. For context, the previous comment used to consist of a single link to https://en.wikipedia.org/wiki/Natural_transformation https://en.wikipedia.org/wiki/Natural_transformation
- bowsamic 3y agoYeah to be honest it's kind of a red flag given the context to see a random term misappropriated in such a way
- deleted 3y ago[deleted]
- agentultra 3y agoYou can define abstractions very precisely in mathematics, that's what makes it useful. You have to get used to the fact that you're talking about the abstraction and not any specific instance/use of it. In the case of monads, the things that are useful which we can say about them: unit is a left identity for bind and also the right identity for bind, etc. What makes an abstraction useful, and is kind of essential in my opinion, are the laws. These do include every case because we don't say anything about specific terms or types, just the laws of bind (in the case of monads). I agree that people keep making them out to be some kind of mountain to climb when, after building up an intuition and learning the fundamental, it turns out they are more of a hill. However I think it takes a good mix of both the theory and application to appreciate how elegant and simple it is in the end.
- bowsamic 3y agoHere is Haskell's Monad: class Monad m where (>>=) :: m a -> ( a -> m b) -> m b (>>) :: m a -> m b -> m b return :: a -> m a and these functions must obey the properties return a >>= k = k a m >>= return = m m >>= (\x -> k x >>= h) = (m >>= k) >>= h Anything other than the definition I gave is an analogy that will only work for certain examples, that is, unless you can mathematically prove that your analogy is isomorphic to this definition
- supermatt 3y agoYeah, my definition works for all those examples.
- bowsamic 3y agoOkay, then prove that your definition of a monad is isomorphic to the given definition
- deleted 3y ago[deleted]
- deleted 3y ago[deleted]
- uxp8u61q 3y agoHow does your "definition" (I will take that to mean "an abstract wrapper for some properties that you can apply sequential transforms on" from your first comment) apply to e.g. the monad whose algebras are monoids?
- nextaccountic 3y ago> The transform is "transform the wrapped properties into some IO call", and all transforms are explicitly sequential. Not every monad has to do with IO. The oddity of Haskell is that Haskell has this IO type and every real world action has to produce an IO value, but the defining characteristic of IO isn't that it's a monad. Now, in the IO type, we use monads to sequence I/O operations, indeed (like "read something to the keyboard, then write this same something you read). But there are other monads that do other things! Monads always enable you to write sequential-looking code (through do notation), sure, but they don't need to execute sequentially - and most of them has nothing to do with IO! For example, the Cont monad enables writing code in continuation-passing style [0], and it's famously difficult to grok [1]. Suffice to say that it enables using the "call with current continuation" operator from Scheme (which doesn't work on IO, but works on Cont) [2] [0] https://www.haskellforall.com/2012/12/the-continuation-monad.html https://www.haskellforall.com/2012/12/the-continuation-monad... [1] https://stackoverflow.com/questions/3322540/how-and-why-does-the-haskell-cont-monad-work https://stackoverflow.com/questions/3322540/how-and-why-does... [2] https://stackoverflow.com/questions/20451022/how-to-interpret-callcc-in-haskell https://stackoverflow.com/questions/20451022/how-to-interpre...