PROPOSAL: Make Applicative a superclass of Monad

[Ashley Yakeley]

I had proposed this to the GHC Trac, but it was pointed out that it
would break Haskell 98. That proposal has been closed.

Proposal:
Make Applicative (in Control.Applicative) a superclass of Monad (in
Control.Monad). Rename members of Applicative and other functions, to
avoid unnecessary duplication. Generalise types of certain existing
functions, as appropriate.

For example:

class Functor f => Applicative f where
   return :: a -> f a
   ap :: f (a -> b) -> f a -> f b
   (>>) :: f a -> f b -> f b
   (>>) = liftA2 (const id)

liftA2 :: Applicative f => (a -> b -> c) -> f a -> f b -> f c
liftA2 f a b = ap (fmap f a) b
-- etc.

class Applicative m => Monad m where
   (>>=) :: m a -> (a -> m b) -> m b
   fail :: String -> m a
   fail s = error s

--
Ashley Yakeley

_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime

[Ashley Yakeley]

I wrote:
> Proposal:
> Make Applicative (in Control.Applicative) a superclass of Monad (in
> Control.Monad).

So does the "silence = approval" rule apply here?

--
Ashley Yakeley

_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime

[Neil Mitchell]

Hi

>  So does the "silence = approval" rule apply here?

2 days is not enough time :-)

I disagree, its a breaking change from Haskell 98. It also means that
if you want to provide syntactic sugar for do notation, i.e. my Test
monad, you have to jump through more hoops.

http://neilmitchell.blogspot.com/2007/06/test-monad.html

Haskell' is about fixing existing practice, if it did go in, you would
need some mechanism (i.e. class aliases) to ensure that it didn't
break code.

Thanks

Neil
_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime

[Niklas Broberg]

>  Haskell' is about fixing existing practice, if it did go in, you would
>  need some mechanism (i.e. class aliases) to ensure that it didn't
>  break code.

... which is why we need class aliases!!

I want to see this change, *and* I want to see class aliases. :-)

Cheers,

/Niklas
_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime

[Sittampalam, Ganesh]

 
> >  Haskell' is about fixing existing practice, if it did go in, you
> > would  need some mechanism (i.e. class aliases) to ensure that it
> > didn't  break code.

> ... which is why we need class aliases!!

> I want to see this change, *and* I want to see class aliases. :-)

I want class aliases, and I want to see this change but *only if* we get
class aliases. Functor =/=> Monad is annoying enough, we shouldn't make
it worse without fixing the underlying limitation first.

Ganesh

==============================================================================
Please access the attached hyperlink for an important electronic communications disclaimer:

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==============================================================================

_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime

[Niklas Broberg]

>  > I want to see this change, *and* I want to see class aliases. :-)
>
> I want class aliases, and I want to see this change but *only if* we get
>  class aliases. Functor =/=> Monad is annoying enough, we shouldn't make
>  it worse without fixing the underlying limitation first.

Yes, agreed, I should have made my point more clear. That's how I feel too.

/Niklas
_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime

[John Meacham]

On Thu, Jun 26, 2008 at 06:25:28PM -0700, Ashley Yakeley wrote:
> I wrote:
>> Proposal:
>> Make Applicative (in Control.Applicative) a superclass of Monad (in
>> Control.Monad).
>
> So does the "silence = approval" rule apply here?

I think that people believe this is generally a good idea, but until the
actual language that is haskell' is formalized, library issues are on
the backburner. But yeah, I think cleaning up various things about the
haskell 98 class hierarchy is a good idea.

Even if class aliases are not in the standard itself but this change
was, implementing class aliasse would allow individual compilers to
provide full back and forwards compatability with haskell 98 and
haskell'.

So, that might be a route to having our cake and eating it too. We can
have the benefit of class aliases without having to break the haskell'
rules and standardize such an immature extension since they were
designed to be 'transparent' to code that doesn't know about them.
Haskell 98 code, and conformant haskell' prime code (as in, code that
doesn't explicitly mention class aliases) will coexist peacefully and we
will get a lot of experience using class aliases for when they
eventually perhaps do get standardized.

        John



--
John Meacham - ⑆repetae.net⑆john⑈
_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime

[Iavor Diatchki]

Hello,
I think that this is a good change to make, and I don't think that it
is in any way related to the introduction of class aliases, which is a
fairly major extension (i.e., it requires changes to the compiler),
that we have no experience with, and whose design has not really be
tried out in practise.

As for breaking Haskell'98 code, Haskell' already makes changes that
break existing code (e.g., the new notation for qualified infix
operators). Cabal's ability to track versioned dependencies between
packages should come in handy in implementing this change.

By the way, I once wrote a module that did exactly what Ashley is
proposing and re-exported everything else from the Prelude, so that
you could use it with GHC's "no-implicit-Prelude" option to try out
the design.  I could dig it out and post it, if anyone is interested.

-Iavor



On Fri, Jun 27, 2008 at 5:16 PM, John Meacham <[hidden email]> wrote:

> On Thu, Jun 26, 2008 at 06:25:28PM -0700, Ashley Yakeley wrote:
>> I wrote:
>>> Proposal:
>>> Make Applicative (in Control.Applicative) a superclass of Monad (in
>>> Control.Monad).
>>
>> So does the "silence = approval" rule apply here?
>
> I think that people believe this is generally a good idea, but until the
> actual language that is haskell' is formalized, library issues are on
> the backburner. But yeah, I think cleaning up various things about the
> haskell 98 class hierarchy is a good idea.
>
> Even if class aliases are not in the standard itself but this change
> was, implementing class aliasse would allow individual compilers to
> provide full back and forwards compatability with haskell 98 and
> haskell'.
>
> So, that might be a route to having our cake and eating it too. We can
> have the benefit of class aliases without having to break the haskell'
> rules and standardize such an immature extension since they were
> designed to be 'transparent' to code that doesn't know about them.
> Haskell 98 code, and conformant haskell' prime code (as in, code that
> doesn't explicitly mention class aliases) will coexist peacefully and we
> will get a lot of experience using class aliases for when they
> eventually perhaps do get standardized.
>
>        John
>
>
>
> --
> John Meacham - ⑆repetae.net⑆john⑈
> _______________________________________________
> Haskell-prime mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-prime
>

_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime

[Ashley Yakeley]

Iavor Diatchki wrote:

> I think that this is a good change to make, and I don't think that it
> is in any way related to the introduction of class aliases, which is a
> fairly major extension (i.e., it requires changes to the compiler),
> that we have no experience with, and whose design has not really be
> tried out in practise.

I agree with this. At worst, without class aliases, it just means
programmers need to copy and paste some boilerplate:

   instance Functor MyMonad where
     fmap = applicative_fmap

   instance Applicative MyMonad where
     ap = monad_ap
     (>>) = monad_aseq
     return = ...

--
Ashley Yakeley

_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime

[Isaac Dupree]

Ashley Yakeley wrote:
> For example:
>
> class Functor f => Applicative f where
>   return :: a -> f a
>   ap :: f (a -> b) -> f a -> f b
>   (>>) :: f a -> f b -> f b
>   (>>) = liftA2 (const id)

for backwards compatibility of everyone who *uses* Applicative, (and
arguably it is a less ugly notation,) :

(<*>) = ap
(and  pure = return)

I'm not sure, is the word "ap" even as well known as "<*>" right now?  I
wonder which one we'd prefer to use in Applicative?

> class Applicative m => Monad m where
>   (>>=) :: m a -> (a -> m b) -> m b
>   fail :: String -> m a
>   fail s = error s

I want to add to this Applicative=>Monad class:

     join :: m (m a) -> m a
     join mm = mm >>= id
     m >>= f = join (fmap f m)

What do others think about that?


(P.S. And I guess this hierarchy change is quite independent of the
difficult task of removing "fail" from Monad, so I won't discuss that
here/now)

-Isaac
_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime