Difference between revisions of "Talk:Functor-Applicative-Monad Proposal"

From HaskellWiki
Jump to: navigation, search
(Pure vs. return)
("fail" has been addressed in the main proposal page)
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
=== Fail ===
 
 
<hask>fail</hask> is useful for the error monad, <hask>Either String a</hask>.
 
 
 
=== Pointed ===
 
=== Pointed ===
   
Line 9: Line 5:
 
== 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. [[User:Jesin|Jesin]] 20:44, 1 January 2011 (UTC)
+
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.

Latest revision as of 20:46, 1 January 2011

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.