On Tue, Jun 29, 2010 at 6:13 PM, Claus Reinke <span dir="ltr"><<a href="mailto:claus.reinke@talk21.com">claus.reinke@talk21.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
The proposal is to move the Monad and MonadFix instances for Either<br>
(currently in the mtl package) to Control.Monad.Instances and<br>
Control.Monad.Fix respectively (both in the base package). The Monad<br>
instance is still an orphan, to retain Haskell 98 compatibility, but the<br>
MonadFix instance is together with its class. The Error constraint is<br>
removed from both instances, and the default definition of fail is used.<br>
</blockquote>
<br></div><div class="im">
-1, because the default definition of fail is error, which would<br>
render the Monad instance useless (unless I'm missing something?).<br>
</div></blockquote><div class="im">
<br>
You would just use Left instead of 'fail' if you want to show failure in an Either value.<br>
</div></blockquote>
<br>
a) you are suggesting to bypass a method of the proposed Monad<br>
instance because it isn't useful, I am suggesting not to define a<br>
Monad instance with unusable methods<br>
b) desugaring of pattern-match failure in Monads calls fail, not Left<br>
<br>
Claus<br>
<br>
PS. I just remembered that I have used 'Monad (Either a)', for<br>
'a' other than String (a parser with error information in addition<br>
to plain error message). That application didn't use<br>
Control.Monad.Errror or Control.Monad.Instances - it could<br>
have been made to fit the current Control.Monad.Error design<br>
but not the proposed design, because it relied on<br>
'fail s `mplus` return x == return x'.</blockquote><div class="h5"> <br>A reasonable case can be made for the existence of a monad that does something useful with fail. I don't think that that monad should be Either.<br>
<br>'Either' takes on the connotation of being the 'sum type' for the category of Haskell types. This sum type has a very well formed and simple monad, that has a lot of useful theoretical properties, and is useful in a strictly larger array of scenarios than the monad with the error constraint, with the one notable exception that it doesn't handle the 'fail' property that was bolted into Monad in Haskell 98. <br>
<br>The obvious name for such a monad would be Error, to go with ErrorT, but the Error class conflicts with that name, but perhaps:<br><br>data Fail e a = Error e | OK a<br><br>would be worth adding to Control.Monad.Error, during the same general timetable as this change, to provide users who really want the existing mtl Either semantics an upgrade path.<br>
<br>In the interest of not killing this proposal with bikeshedding concerns over what to call it (Fail, Err, Error, etc), we should probably put that forward as a completely separate libraries proposal though.<br><br>It would address the confusion caused to new users who often on #haskell ask why 'Left' is the error case, and would address your use case explicitly, and even less verbosely. ;)<br>
<br>-Edward Kmett<br></div></div>