Hello,
I think that we should make both changes (make Applicative a
super-class of Monad, and remove the "fail" method from Monad). Code
will break but we can fix it.
By the way, just for reference, the proposal to have a separate
failure class and using it in the "do" notation, is how things us
IO
On Thu, Dec 16, 2010 at 6:03 PM, John Smith wrote:
> On 15/12/2010 14:31, Lennart Augustsson wrote:
>
>> Yes, I think there should be a MonadFail distinct from MonadPlus.
>> Some types, like IO, are not in MonadPlus, but have a special
>> implementation of the fail method.
>>
>> Personally, I
On Thu, Dec 16, 2010 at 12:03 PM, John Smith wrote:
> On 15/12/2010 14:31, Lennart Augustsson wrote:
>>
>> Yes, I think there should be a MonadFail distinct from MonadPlus.
>> Some types, like IO, are not in MonadPlus, but have a special
>> implementation of the fail method.
>>
>> Personally, I th
On 15/12/2010 14:31, Lennart Augustsson wrote:
Yes, I think there should be a MonadFail distinct from MonadPlus.
Some types, like IO, are not in MonadPlus, but have a special implementation of
the fail method.
Personally, I think fail should just be removed, but that would break existing
code.
On 15 Dec 2010, at 17:48, Brent Yorgey wrote:
On Wed, Dec 15, 2010 at 06:25:30PM +0100, Maciej Piechotka wrote:
On Wed, 2010-12-15 at 13:51 +0200, John Smith wrote:
On 15/12/2010 11:39, Lennart Augustsson wrote:
Any refutable pattern match in do would force MonadFail (or
MonadPlus if you pr
On Wed, Dec 15, 2010 at 06:25:30PM +0100, Maciej Piechotka wrote:
> On Wed, 2010-12-15 at 13:51 +0200, John Smith wrote:
> > On 15/12/2010 11:39, Lennart Augustsson wrote:
> > > Any refutable pattern match in do would force MonadFail (or MonadPlus if
> > > you prefer). So
> > > 1. (MonadFail m)
On Wed, 2010-12-15 at 13:51 +0200, John Smith wrote:
> On 15/12/2010 11:39, Lennart Augustsson wrote:
> > Any refutable pattern match in do would force MonadFail (or MonadPlus if
> > you prefer). So
> > 1. (MonadFail m) => a -> m a, \ a -> return a
> > 2. (MonadFail m) => m a, mfail "..."
>
Yes, I think there should be a MonadFail distinct from MonadPlus.
Some types, like IO, are not in MonadPlus, but have a special implementation
of the fail method.
Personally, I think fail should just be removed, but that would break
existing code.
The fail method was introduced for the wrong reaso
On 15/12/2010 11:39, Lennart Augustsson wrote:
Any refutable pattern match in do would force MonadFail (or MonadPlus if you
prefer). So
1. (MonadFail m) => a -> m a, \ a -> return a
2. (MonadFail m) => m a, mfail "..."
3. (MonadFail m) => Maybe a -> m a, \ a -> case a of Nothing -> mfa
John Smith proposed:
a failed pattern match should error in the same way as is does for
pure code, while in MonadPlus, the current behaviour could be
maintained with mzero
Lennart Augustsson wrote:
Any refutable pattern match in do would force MonadFail (or MonadPlus
if you prefer).
I guess
Any refutable pattern match in do would force MonadFail (or MonadPlus if you
prefer). So
1. (MonadFail m) => a -> m a, \ a -> return a
2. (MonadFail m) => m a, mfail "..."
3. (MonadFail m) => Maybe a -> m a, \ a -> case a of Nothing -> mfail
"..."; Just x -> return x
4. (Monad m) => a ->
Hi John,
John Smith wrote:
Perhaps pattern match failures in a MonadPlus should bind to mzero - I
believe that this is what your example and similar wish to achieve.
You updated the proposal to say:
a failed pattern match should error in the same way as is does for pure code,
while in
MonadP
On 15/12/2010 04:01, Jonathan Geddes wrote:
Fail can't just be removed. That would just break too much code. For
example, I find myself writing code like the following:
[a,b,c]<- Just someList
in place of
let [a,b,c] = someList
so that pattern match failure is "lifted" into the maybe mona
Fail can't just be removed. That would just break too much code. For
example, I find myself writing code like the following:
>[a,b,c] <- Just someList
in place of
>let [a,b,c] = someList
so that pattern match failure is "lifted" into the maybe monad (as
long as I'm already in the maybe monad).
2010/12/14 Tillmann Rendel :
> Hi,
>
> John Smith wrote:
>>
>> I would like to formally propose that Monad become a subclass of
>> Applicative
>
> A lot of code would break because of this change, but all problems should be
> reported at compile time, and are easy to fix. In most of the cases, eith
Hi,
John Smith wrote:
I would like to formally propose that Monad become a subclass of
Applicative
A lot of code would break because of this change, but all problems
should be reported at compile time, and are easy to fix. In most of the
cases, either adding obvious Functor and Applicative i
[switching to cafe]
On 14 Dec 2010, at 08:59, Sittampalam, Ganesh wrote:
John Smith wrote:
I would like to formally propose that Monad become a subclass of
Applicative, with a call for consensus by 1 February.
I would prefer that we have some proposal like class aliases
implemented
before
17 matches
Mail list logo