PROPOSAL: Make Applicative a superclass of Monad

[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 <john at repetae.net> 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
> Haskell-prime at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-prime
>