4 ms·

Minor nitpicks: "Monadic types" and "Monadic values" would be better for 4 and 5, because "Monad types" are the type constructors (which are also sometimes nam

by Peaker 14y ago

Minor nitpicks: "Monadic types" and "Monadic values" would be better for 4 and 5, because "Monad types" are the type constructors (which are also sometimes named types). And "monad values" is not a term I've ever heard used. Also, values have-type, they're not instance-of. So it would be slightly more accurate to say monadic values are values of a monadic type, whose type constructor is an instance of the Monad type-class. I agree better and more accurate use of accepted terminology for all these concepts could be useful. As for the namespacing issue in the examples, it might be confusing for a complete beginner, but one of the first things you learn in Haskell (ideally before Monads) is how scoping works.

DannoHung 14y ago
I'm sure I've made some terminology decisions that are questionable, but in light of someone writing the community approved guide to talking about monads, I'll try to explain what I was trying to get across. First, I was trying to emphasize that a type constructor is not strictly a type in the sense of a value having a type. While we commonly speak about to the parameterized types without their type arguments, they aren't really "types" in the type theory sense while there are still type arguments to be supplied. That is, "Maybe"'s kind is * -> * while Maybe a's kind is * even though a is a generic type. When referring to something as a "monadic value" I was just trying to emphasize that the monad that contains a value is itself a value in the Haskell runtime system and that such a "monadic value" is separate from the value contained there within. Finally, maybe this is a bad habit of mine, but I've always referred to values as instances since they inhabit types. I disagree that the namespacing is only ever an issue for a complete beginner. The visual separation between a type expression and a value expression in Haskell can be pretty thin. It's not just about whether they are unambiguous but how much attention you have to pay to while you're skimming code. Honestly, I don't think there's much that can be done about it, but it's just the cherry on top for beginner and intermediate users. Especially ones who aren't using Haskell regularly.

by Peaker 14y ago

DannoHung 14y ago

I'm sure I've made some terminology decisions that are questionable, but in light of someone writing the community approved guide to talking about monads, I'll try to explain what I was trying to get across. First, I was trying to emphasize that a type constructor is not strictly a type in the sense of a value having a type. While we commonly speak about to the parameterized types without their type arguments, they aren't really "types" in the type theory sense while there are still type arguments to be supplied. That is, "Maybe"'s kind is * -> * while Maybe a's kind is * even though a is a generic type. When referring to something as a "monadic value" I was just trying to emphasize that the monad that contains a value is itself a value in the Haskell runtime system and that such a "monadic value" is separate from the value contained there within. Finally, maybe this is a bad habit of mine, but I've always referred to values as instances since they inhabit types. I disagree that the namespacing is only ever an issue for a complete beginner. The visual separation between a type expression and a value expression in Haskell can be pretty thin. It's not just about whether they are unambiguous but how much attention you have to pay to while you're skimming code. Honestly, I don't think there's much that can be done about it, but it's just the cherry on top for beginner and intermediate users. Especially ones who aren't using Haskell regularly.