Difference between revisions of "Talk:Functor-Applicative-Monad Proposal"
Jump to navigation
Jump to search
| Line 9: | Line 9: | ||
== Pure vs. return == |
== Pure vs. return == |
||
| − | When combining <hask>pure</hask> and <hask>return</hask>, perhaps we should call it <hask>pure</hask>, or something else that is not <hask>return</hask>? It would defy convention, yes, but we would already be making changes that would require a Legacy module for backwards compatability, and it may reduce confusion over what the function actually does, because Haskell's <hask>return</hask> is nothing like "return" in other languages. |
+ | When combining <hask>pure</hask> and <hask>return</hask>, perhaps we should call it <hask>pure</hask>, or something else that is not <hask>return</hask>? It would defy convention, yes, but we would already be making changes that would require a Legacy module for backwards compatability, and it may reduce confusion over what the function actually does, because Haskell's <hask>return</hask> is nothing like "return" in other languages. |
Revision as of 20:44, 1 January 2011
Fail
fail is useful for the error monad, Either String a.
Pointed
If return is the only method of the Pointed class then Pointed should be included in the hierarchy. Better to be exactly mathematically correct once and for all.
Pure vs. return
When combining pure and return, perhaps we should call it pure, or something else that is not return? It would defy convention, yes, but we would already be making changes that would require a Legacy module for backwards compatability, and it may reduce confusion over what the function actually does, because Haskell's return is nothing like "return" in other languages.