David Luposchainsky | 23 May 21:39 2013

2014 Applicative => Monad proposal

Hello libraries,

it's on! Time to tackle the Applicative-Monad issue, hopefully once and
for all. Over the last couple of weeks I've looked through previous
proposals, asked #haskell about their opinions, and compiled it all into
one file that sums up what I made of that. It's a bit long for an email
and uses markdown, so I'll just provide links at the end of this mail
instead of pasting it in here. In there, the whole thing and how to
approach it is explained in more detail. Here's an abstract of what it
the proposal consists of:

- Don't break compatibility
- Apply it gently

- Applicative m => Monad m
- Applicative into Prelude (and therefore into the Report)
- (Alternative m, Monad m) => MonadPlus m
- Promote `join` into the Monad typeclass

Let's make this happen! I'm going to give a ballpark discussion period
of four weeks, but since I can imagine this discussion could become
quite complex we shouldn't take it too serious. I'll summarize what's
been going on periodically though.

David

Links:

The proposal text on Github (link fixed, sorry for the deadlink yesterday):
https://github.com/quchen/articles/blob/master/applicative_monad.md
(Continue reading)

Henning Thielemann | 23 May 21:56 2013
Picon

Re: 2014 Applicative => Monad proposal


On Thu, 23 May 2013, David Luposchainsky wrote:

> Let's make this happen! I'm going to give a ballpark discussion period
> of four weeks, but since I can imagine this discussion could become
> quite complex we shouldn't take it too serious. I'll summarize what's
> been going on periodically though.

I like the proposal and the plan for a transition.

I am only concerned with this one:

> - Promote `join` into the Monad typeclass

Currently, when I forget to implement the two essential Monad methods 
'return' and '>>=' in a Monad instance, I get a warning. However with the 
mutual implementations of 'join' and '>>=' I do not get a warning but an 
infinite loop. Similarly, I already had nasty bugs with (a-b) defaulting 
to (a + negate b) and (negate a) defaulting to (0-a).
Nicolas Trangez | 23 May 22:00 2013

Re: 2014 Applicative => Monad proposal

On Thu, 2013-05-23 at 21:56 +0200, Henning Thielemann wrote:
> I am only concerned with this one:
> 
> > - Promote `join` into the Monad typeclass
> 
> Currently, when I forget to implement the two essential Monad methods 
> 'return' and '>>=' in a Monad instance, I get a warning. However with the 
> mutual implementations of 'join' and '>>=' I do not get a warning but an 
> infinite loop. Similarly, I already had nasty bugs with (a-b) defaulting 
> to (a + negate b) and (negate a) defaulting to (0-a).

http://hackage.haskell.org/trac/ghc/ticket/7633 might help.

Nicolas
Henning Thielemann | 23 May 22:25 2013
Picon

Re: 2014 Applicative => Monad proposal


On Thu, 23 May 2013, Nicolas Trangez wrote:

> On Thu, 2013-05-23 at 21:56 +0200, Henning Thielemann wrote:
>> I am only concerned with this one:
>>
>>> - Promote `join` into the Monad typeclass
>>
>> Currently, when I forget to implement the two essential Monad methods
>> 'return' and '>>=' in a Monad instance, I get a warning. However with the
>> mutual implementations of 'join' and '>>=' I do not get a warning but an
>> infinite loop. Similarly, I already had nasty bugs with (a-b) defaulting
>> to (a + negate b) and (negate a) defaulting to (0-a).
>
> http://hackage.haskell.org/trac/ghc/ticket/7633 might help.

Then I withdraw my concerns.
Dan Burton | 23 May 22:34 2013
Picon

Re: 2014 Applicative => Monad proposal

+1 to the type class hierarchy enhancements
+1 to the {-# MINIMAL #-} pragma being added to GHC (and even to Haskell) in conjunction with this change to assuage concerns. And color *that* bikeshed any way you like; just give me the feature.

Well thought out, well presented. Let's move to the next phase, well executed!

-- Dan Burton


On Thu, May 23, 2013 at 1:25 PM, Henning Thielemann <lemming <at> henning-thielemann.de> wrote:

On Thu, 23 May 2013, Nicolas Trangez wrote:

On Thu, 2013-05-23 at 21:56 +0200, Henning Thielemann wrote:
I am only concerned with this one:

- Promote `join` into the Monad typeclass

Currently, when I forget to implement the two essential Monad methods
'return' and '>>=' in a Monad instance, I get a warning. However with the
mutual implementations of 'join' and '>>=' I do not get a warning but an
infinite loop. Similarly, I already had nasty bugs with (a-b) defaulting
to (a + negate b) and (negate a) defaulting to (0-a).

http://hackage.haskell.org/trac/ghc/ticket/7633 might help.

Then I withdraw my concerns.


_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Herbert Valerio Riedel | 23 May 22:17 2013
Picon

declaring minimal complete instance definition (was: 2014 Applicative => Monad proposal)

On 2013-05-23 21:56:30 +0200, Henning Thielemann wrote:

[...]

> Currently, when I forget to implement the two essential Monad methods
> return' and '>>=' in a Monad instance, I get a warning. However with
> the mutual implementations of 'join' and '>>=' I do not get a warning
> but an infinite loop. Similarly, I already had nasty bugs with (a-b)
> defaulting to (a + negate b) and (negate a) defaulting to (0-a).

As this is a general problem which comes up often with mutually
recursive default implementations for typeclass methods, I have been
wondering if somebody came up with a solution for that, which allows the
compiler to emit warnings or even errors.

Often the documentation for a typeclass already specifies the "minimal
complete definition", if this could be meta-annotated with some pragma
for the compiler to pick up, we could have the compiler help us avoid
invalid instance definition. Has some ghc-feature/extension to this
effect been discussed in the past?

Btw, even the simple 'Eq' and 'Ord' classes have mutually depending
    default implementations:

 - Eq: "Minimal complete definition: either '==' or '/='."

 - Ord: "Minimal complete definition: either 'compare' or '<='. Using
        'compare' can be more efficient for complex types."

cheers,
  hvr
Shachaf Ben-Kiki | 23 May 22:20 2013
Picon

Re: declaring minimal complete instance definition (was: 2014 Applicative => Monad proposal)

On Thu, May 23, 2013 at 4:17 PM, Herbert Valerio Riedel <hvr <at> gnu.org> wrote:
> As this is a general problem which comes up often with mutually
> recursive default implementations for typeclass methods, I have been
> wondering if somebody came up with a solution for that, which allows the
> compiler to emit warnings or even errors.
>
> Often the documentation for a typeclass already specifies the "minimal
> complete definition", if this could be meta-annotated with some pragma
> for the compiler to pick up, we could have the compiler help us avoid
> invalid instance definition. Has some ghc-feature/extension to this
> effect been discussed in the past?
>
>
> Btw, even the simple 'Eq' and 'Ord' classes have mutually depending
>     default implementations:
>
>  - Eq: "Minimal complete definition: either '==' or '/='."
>
>  - Ord: "Minimal complete definition: either 'compare' or '<='. Using
>         'compare' can be more efficient for complex types."
>
> cheers,
>   hvr
>

See my proposal along these lines from a few months ago to implement
this as a pragma in GHC:

http://hackage.haskell.org/trac/ghc/ticket/7633

    Shachaf
Twan van Laarhoven | 28 May 20:00 2013
Picon

Re: declaring minimal complete instance definition

On 23/05/13 22:20, Shachaf Ben-Kiki wrote:
> On Thu, May 23, 2013 at 4:17 PM, Herbert Valerio Riedel <hvr <at> gnu.org> wrote:
>> As this is a general problem which comes up often with mutually
>> recursive default implementations for typeclass methods, I have been
>> wondering if somebody came up with a solution for that, which allows the
>> compiler to emit warnings or even errors.
>>
>> Often the documentation for a typeclass already specifies the "minimal
>> complete definition", if this could be meta-annotated with some pragma
>> for the compiler to pick up, we could have the compiler help us avoid
>> invalid instance definition. Has some ghc-feature/extension to this
>> effect been discussed in the past?
>>
>>
>> Btw, even the simple 'Eq' and 'Ord' classes have mutually depending
>>      default implementations:
>>
>>   - Eq: "Minimal complete definition: either '==' or '/='."
>>
>>   - Ord: "Minimal complete definition: either 'compare' or '<='. Using
>>          'compare' can be more efficient for complex types."
>>
>> cheers,
>>    hvr
>>
>
> See my proposal along these lines from a few months ago to implement
> this as a pragma in GHC:
>
> http://hackage.haskell.org/trac/ghc/ticket/7633
>
>      Shachaf

I have made an implementation, the patch is attached to that ticket.

Twan
Edward Kmett | 23 May 22:44 2013
Picon

Re: 2014 Applicative => Monad proposal

+1 on doing this. Period.

That said, there are a couple of ways that this proposal could be pragmatically improved.

The DefaultSignatures extension could be used to permit (GHC) users to avoid having to define definitions for the Functor and Applicative combinators (for simple monads, anyways.)

class Functor f where
   fmap :: (a -> b) -> f a -> f b
#ifdef __DEFAULT_SIGNATURES__
   default fmap :: Monad f => (a -> b) -> f a -> f b
   fmap = liftM
#endif

class Functor f => Applicative f where
   pure :: a -> f a
#ifdef __DEFAULT_SIGNATURES__
   default pure :: Monad f => a -> f a
   pure = return
#endif

   (<*>) :: f (a -> b) -> f a -> f b
#ifdef __DEFAULT_SIGNATURES__
   default (<*>) :: Monad f => f (a -> b) -> f a -> f b
   (<*>) = ap
#endif

This would have the side-effect of replacing the return = pure definition though.

I offer it as a potential refinement on its own, that comes with its own benefits and limitations, but I want to be clear, my approval for this proposal stands regardless of this detail!

-Edward



On Thu, May 23, 2013 at 3:39 PM, David Luposchainsky <dluposchainsky <at> googlemail.com> wrote:
Hello libraries,

it's on! Time to tackle the Applicative-Monad issue, hopefully once and
for all. Over the last couple of weeks I've looked through previous
proposals, asked #haskell about their opinions, and compiled it all into
one file that sums up what I made of that. It's a bit long for an email
and uses markdown, so I'll just provide links at the end of this mail
instead of pasting it in here. In there, the whole thing and how to
approach it is explained in more detail. Here's an abstract of what it
the proposal consists of:


- Don't break compatibility
- Apply it gently

- Applicative m => Monad m
- Applicative into Prelude (and therefore into the Report)
- (Alternative m, Monad m) => MonadPlus m
- Promote `join` into the Monad typeclass


Let's make this happen! I'm going to give a ballpark discussion period
of four weeks, but since I can imagine this discussion could become
quite complex we shouldn't take it too serious. I'll summarize what's
been going on periodically though.

David



Links:

The proposal text on Github (link fixed, sorry for the deadlink yesterday):
https://github.com/quchen/articles/blob/master/applicative_monad.md
(This file is subject to changes, depending on how this discussion goes.
I'll try to make it reflect the current consensus.)

And just in case Github silentbans me again for submitting too many
edits to my Gist (grrr), here's a copy of the file on HPaste as backup:
http://hpaste.org/88423

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Jeremy Shaw | 23 May 22:50 2013

Re: 2014 Applicative => Monad proposal

Great! I'd loved to see Pointed in there too -- but I have no dreams
of winning that one. :p

Hopefully this will pave the way for a MonadFail in the future, and
other enhancements.

I maintain Happstack, a bunch of related libraries, and a bunch of
code that uses Happstack, etc. So, I am potentially affected by any
breakage -- but that is fine by me.

Sure we have thousands of users now.. but let's fix this before we
have millions!

- jeremy

On Thu, May 23, 2013 at 2:39 PM, David Luposchainsky
<dluposchainsky <at> googlemail.com> wrote:
> Hello libraries,
>
> it's on! Time to tackle the Applicative-Monad issue, hopefully once and
> for all. Over the last couple of weeks I've looked through previous
> proposals, asked #haskell about their opinions, and compiled it all into
> one file that sums up what I made of that. It's a bit long for an email
> and uses markdown, so I'll just provide links at the end of this mail
> instead of pasting it in here. In there, the whole thing and how to
> approach it is explained in more detail. Here's an abstract of what it
> the proposal consists of:
>
>
> - Don't break compatibility
> - Apply it gently
>
> - Applicative m => Monad m
> - Applicative into Prelude (and therefore into the Report)
> - (Alternative m, Monad m) => MonadPlus m
> - Promote `join` into the Monad typeclass
>
>
> Let's make this happen! I'm going to give a ballpark discussion period
> of four weeks, but since I can imagine this discussion could become
> quite complex we shouldn't take it too serious. I'll summarize what's
> been going on periodically though.
>
> David
>
>
>
> Links:
>
> The proposal text on Github (link fixed, sorry for the deadlink yesterday):
> https://github.com/quchen/articles/blob/master/applicative_monad.md
> (This file is subject to changes, depending on how this discussion goes.
> I'll try to make it reflect the current consensus.)
>
> And just in case Github silentbans me again for submitting too many
> edits to my Gist (grrr), here's a copy of the file on HPaste as backup:
> http://hpaste.org/88423
>
> _______________________________________________
> Libraries mailing list
> Libraries <at> haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
Henning Thielemann | 23 May 22:56 2013
Picon

More monad proposals (Was: 2014 Applicative => Monad proposal)


On Thu, 23 May 2013, Jeremy Shaw wrote:

> Great! I'd loved to see Pointed in there too

precautionarily +1

> Hopefully this will pave the way for a MonadFail in the future,

+1
Dan Burton | 24 May 01:17 2013
Picon

Re: More monad proposals (Was: 2014 Applicative => Monad proposal)

-0.1 for Pointed. What's the point? (pun intended, but seriously)
+1 for MonadFail in the near future. Having this in Haskell 2014 would be nice.

-- Dan Burton


On Thu, May 23, 2013 at 1:56 PM, Henning Thielemann <lemming <at> henning-thielemann.de> wrote:

On Thu, 23 May 2013, Jeremy Shaw wrote:

Great! I'd loved to see Pointed in there too

precautionarily +1


Hopefully this will pave the way for a MonadFail in the future,

+1

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Ben Millwood | 23 May 23:46 2013
Picon

Re: 2014 Applicative => Monad proposal

On Thu, May 23, 2013 at 03:50:40PM -0500, Jeremy Shaw wrote:
>Great! I'd loved to see Pointed in there too -- but I have no dreams
>of winning that one. :p

I'm of the opinion that Pointed is excessive granularity. See also:
http://www.haskell.org/haskellwiki/Why_not_Pointed?

In general, with regards to the difficulty keeping track of facts and 
discussions, I think it could be a good idea to use the wiki more. I 
mean, discussion is best on the mailing list, but I feel like the 
original proposals and facts of the matter could stand to go there, so 
that they're easily-retrieved later on.

Anyway. +1 AMP from me.

I'm a little uneasy about default signatures. In particular, if I write 
code assuming that they exist, can it be compiled by compilers which 
don't support it, and just result in a missing method?
Edward Kmett | 23 May 23:53 2013
Picon

Re: 2014 Applicative => Monad proposal

Ben,

Yeah, if you wanted to write code to be compatible with non-GHC compilers, yes, you'd have to supply the methods anyways.

This is pretty much what I do with anything remotely portable that I write. I put in default signatures so folks who aren't concerned with portability can get ease of use and then i bother to put the default definitions for my own methods unless i'm writing something highly GHC-specific that can't work with another compiler anyways.

I'd be perfectly okay with just saying +1 to the proposal as it stands. DefaultSignatures have somewhat annoying nuances. e.g. you have to have the subclass present where you define the superclass, which means internally Functor, Applicative and Monad would need to live in the same module somewhere, before being re-exported from their current homes, and then missing definitions upgrade from a simple warning to a full error about not being able to find the instances required for the default signature.

I mentioned it mostly to remind folks that it does provide an alternative to some of the plumbing used in this proposal -- not intending to gum up the works!

-Edward


On Thu, May 23, 2013 at 5:46 PM, Ben Millwood <haskell <at> benmachine.co.uk> wrote:
On Thu, May 23, 2013 at 03:50:40PM -0500, Jeremy Shaw wrote:
Great! I'd loved to see Pointed in there too -- but I have no dreams
of winning that one. :p

I'm of the opinion that Pointed is excessive granularity. See also:
http://www.haskell.org/haskellwiki/Why_not_Pointed?

In general, with regards to the difficulty keeping track of facts and discussions, I think it could be a good idea to use the wiki more. I mean, discussion is best on the mailing list, but I feel like the original proposals and facts of the matter could stand to go there, so that they're easily-retrieved later on.

Anyway. +1 AMP from me.

I'm a little uneasy about default signatures. In particular, if I write code assuming that they exist, can it be compiled by compilers which don't support it, and just result in a missing method?


_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Stephen Tetley | 23 May 23:34 2013
Picon

Re: 2014 Applicative => Monad proposal

(+1) I would like to see this proposal go forward.

Though I've previously expressed a preference for Monad/Applicative
changes being ratified as part of a language revision - I've changed
my mind in the last few days.

Thanks to both David in this thread and Simon Peyton-Jones in the
"Making Decisions" thread for constructive proposals, that hopefully
will both see fruition.
David Luposchainsky | 23 May 23:44 2013

Re: 2014 Applicative => Monad proposal

On 2013-05-23 23:34, Stephen Tetley wrote:
> Though I've previously expressed a preference for Monad/Applicative
> changes being ratified as part of a language revision - I've changed
> my mind in the last few days.

I don't think you even need to change your preference here: the key idea
of this proposal is that it is possible to be applied almost entirely
without changing the standard. Once the Haskell landscape has complying
code, the step from recommending to enforcing the AMP is a very small one.

David
Bas van Dijk | 24 May 00:01 2013
Picon

Re: 2014 Applicative => Monad proposal

+1 for AMP.

I hope it makes it this time.

On 23 May 2013 23:44, David Luposchainsky <dluposchainsky <at> googlemail.com> wrote:
> On 2013-05-23 23:34, Stephen Tetley wrote:
>> Though I've previously expressed a preference for Monad/Applicative
>> changes being ratified as part of a language revision - I've changed
>> my mind in the last few days.
>
> I don't think you even need to change your preference here: the key idea
> of this proposal is that it is possible to be applied almost entirely
> without changing the standard. Once the Haskell landscape has complying
> code, the step from recommending to enforcing the AMP is a very small one.

One interesting question about the Haskell Report is if we should
generalize the following translation:

do {e;stmts}=e >> do {stmts}

to:

do {e;stmts}=e *> do {stmts}

Bas
Dan Doel | 24 May 02:23 2013
Picon

Re: 2014 Applicative => Monad proposal

+1


On Thu, May 23, 2013 at 6:01 PM, Bas van Dijk <v.dijk.bas <at> gmail.com> wrote:
One interesting question about the Haskell Report is if we should
generalize the following translation:

do {e;stmts}=e >> do {stmts}

to:

do {e;stmts}=e *> do {stmts}

There are other situations where one can desugar to just applicatives that I wouldn't mind seeing. But they of course haven't been implemented anywhere.

For instance, the comprehension:

    [ e1 | x <- e2, y <- e3, ... ]

can be translated to:

    (\x y ... -> e1) <$> e2 <*> ...

so long as x, y ... aren't free in e2, e3 ....

I don't think any of this should be considered until the details have been worked out and implemented, of course.
_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Ivan Lazar Miljenovic | 24 May 02:02 2013
Picon

Re: 2014 Applicative => Monad proposal

On 24 May 2013 05:39, David Luposchainsky <dluposchainsky <at> googlemail.com> wrote:
> Hello libraries,
>
> it's on! Time to tackle the Applicative-Monad issue, hopefully once and
> for all. Over the last couple of weeks I've looked through previous
> proposals, asked #haskell about their opinions, and compiled it all into
> one file that sums up what I made of that. It's a bit long for an email
> and uses markdown, so I'll just provide links at the end of this mail
> instead of pasting it in here. In there, the whole thing and how to
> approach it is explained in more detail. Here's an abstract of what it
> the proposal consists of:
>
>
> - Don't break compatibility
> - Apply it gently
>
> - Applicative m => Monad m
> - Applicative into Prelude (and therefore into the Report)
> - (Alternative m, Monad m) => MonadPlus m
> - Promote `join` into the Monad typeclass

How about removing `return' from the Monad typeclass and just making
it an alias for pure?  Or is it being kept just to minimise breakage
from existing instance declarations?

Anyway, I agree with the first three; I'm not fussed either way with
including `join' into the typeclass.

>
>
> Let's make this happen! I'm going to give a ballpark discussion period
> of four weeks, but since I can imagine this discussion could become
> quite complex we shouldn't take it too serious. I'll summarize what's
> been going on periodically though.
>
> David
>
>
>
> Links:
>
> The proposal text on Github (link fixed, sorry for the deadlink yesterday):
> https://github.com/quchen/articles/blob/master/applicative_monad.md
> (This file is subject to changes, depending on how this discussion goes.
> I'll try to make it reflect the current consensus.)
>
> And just in case Github silentbans me again for submitting too many
> edits to my Gist (grrr), here's a copy of the file on HPaste as backup:
> http://hpaste.org/88423
>
> _______________________________________________
> Libraries mailing list
> Libraries <at> haskell.org
> http://www.haskell.org/mailman/listinfo/libraries

--

-- 
Ivan Lazar Miljenovic
Ivan.Miljenovic <at> gmail.com
http://IvanMiljenovic.wordpress.com
Jason Dagit | 24 May 02:18 2013
Picon

Re: 2014 Applicative => Monad proposal

On Thu, May 23, 2013 at 5:02 PM, Ivan Lazar Miljenovic
<ivan.miljenovic <at> gmail.com> wrote:
> On 24 May 2013 05:39, David Luposchainsky <dluposchainsky <at> googlemail.com> wrote:
>> Hello libraries,
>>
>> it's on! Time to tackle the Applicative-Monad issue, hopefully once and
>> for all. Over the last couple of weeks I've looked through previous
>> proposals, asked #haskell about their opinions, and compiled it all into
>> one file that sums up what I made of that. It's a bit long for an email
>> and uses markdown, so I'll just provide links at the end of this mail
>> instead of pasting it in here. In there, the whole thing and how to
>> approach it is explained in more detail. Here's an abstract of what it
>> the proposal consists of:
>>
>>
>> - Don't break compatibility
>> - Apply it gently
>>
>> - Applicative m => Monad m
>> - Applicative into Prelude (and therefore into the Report)
>> - (Alternative m, Monad m) => MonadPlus m
>> - Promote `join` into the Monad typeclass
>
> How about removing `return' from the Monad typeclass and just making
> it an alias for pure?  Or is it being kept just to minimise breakage
> from existing instance declarations?

Relevant to this suggestion:
https://groups.google.com/group/idris-lang/browse_thread/thread/e137645db268490

Basically, someone is refactoring the Idris typeclasses to add
Applicative as a superclass of Monad and observed the same thing.

Jason
Dan Burton | 24 May 02:26 2013
Picon

Re: 2014 Applicative => Monad proposal

I think that removing return from the Monad class and making it an alias of pure is the Right Thing to Do, but not yet. The proposal, as it stands, is very tasteful about how little it breaks. Let's keep `return = pure` on the back-burner for a while.

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
John Lato | 24 May 03:39 2013
Picon

Re: 2014 Applicative => Monad proposal

+1 for AMP (with or without DefaultSignatures)
+1 for MINIMAL pragma


On Fri, May 24, 2013 at 8:26 AM, Dan Burton <danburton.email <at> gmail.com> wrote:
I think that removing return from the Monad class and making it an alias of pure is the Right Thing to Do, but not yet. The proposal, as it stands, is very tasteful about how little it breaks. Let's keep `return = pure` on the back-burner for a while.
_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
John Wiegley | 24 May 09:29 2013

Re: 2014 Applicative => Monad proposal

>>>>> John Lato <jwlato <at> gmail.com> writes:

> +1 for AMP (with or without DefaultSignatures)

+1 for AMP

--

-- 
John Wiegley
FP Complete                         Haskell tools, training and consulting
http://fpcomplete.com               johnw on #haskell/irc.freenode.net
Andreas Abel | 24 May 17:13 2013
Picon

Re: 2014 Applicative => Monad proposal

+1 AMP
+1 MINIMAL
+1 Pointed in base

On 24.05.2013 03:39, John Lato wrote:
> +1 for AMP (with or without DefaultSignatures)
> +1 for MINIMAL pragma
>
>
> On Fri, May 24, 2013 at 8:26 AM, Dan Burton <danburton.email <at> gmail.com
> <mailto:danburton.email <at> gmail.com>> wrote:
>
>     I think that removing return from the Monad class and making it an
>     alias of pure is the Right Thing to Do, but not yet. The proposal,
>     as it stands, is very tasteful about how little it breaks. Let's
>     keep `return = pure` on the back-burner for a while.
>     _______________________________________________
>     Libraries mailing list
>     Libraries <at> haskell.org <mailto:Libraries <at> haskell.org>
>     http://www.haskell.org/mailman/listinfo/libraries
>
>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries <at> haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>

--

-- 
Andreas Abel  <><      Du bist der geliebte Mensch.

Theoretical Computer Science, University of Munich
Oettingenstr. 67, D-80538 Munich, GERMANY

andreas.abel <at> ifi.lmu.de
http://www2.tcs.ifi.lmu.de/~abel/
Edward Kmett | 24 May 17:20 2013
Picon

Re: 2014 Applicative => Monad proposal

For the record I'm actually -1 on including Pointed.

My experience is that there are very few uses for the class that permit you to reason about your code without one-off ad hoc reasoning based on the particular instance you are given. Now, the Apply and Bind classes on the other hand... =) Though, to be fair, I couldn't seriously propose including either of those, either. Even I can't be bothered to instantiate them all the time!

-Edward


On Fri, May 24, 2013 at 11:13 AM, Andreas Abel <andreas.abel <at> ifi.lmu.de> wrote:
+1 AMP
+1 MINIMAL
+1 Pointed in base


On 24.05.2013 03:39, John Lato wrote:
+1 for AMP (with or without DefaultSignatures)
+1 for MINIMAL pragma


On Fri, May 24, 2013 at 8:26 AM, Dan Burton <danburton.email <at> gmail.com
<mailto:danburton.email <at> gmail.com>> wrote:

    I think that removing return from the Monad class and making it an
    alias of pure is the Right Thing to Do, but not yet. The proposal,
    as it stands, is very tasteful about how little it breaks. Let's
    keep `return = pure` on the back-burner for a while.
    _______________________________________________
    Libraries mailing list
    Libraries <at> haskell.org <mailto:Libraries <at> haskell.org>
    http://www.haskell.org/mailman/listinfo/libraries





_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries



--
Andreas Abel  <><      Du bist der geliebte Mensch.

Theoretical Computer Science, University of Munich
Oettingenstr. 67, D-80538 Munich, GERMANY

andreas.abel <at> ifi.lmu.de
http://www2.tcs.ifi.lmu.de/~abel/


_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Roman Cheplyaka | 24 May 17:28 2013

Re: 2014 Applicative => Monad proposal

I completely agree with Edward here.

* Edward Kmett <ekmett <at> gmail.com> [2013-05-24 11:20:51-0400]
> For the record I'm actually -1 on including Pointed.
> 
> My experience is that there are very few uses for the class that permit you
> to reason about your code without one-off ad hoc reasoning based on the
> particular instance you are given. Now, the Apply and Bind classes on the
> other hand... =) Though, to be fair, I couldn't seriously propose including
> either of those, either. Even I can't be bothered to instantiate them all
> the time!
> 
> -Edward
> 
> 
> On Fri, May 24, 2013 at 11:13 AM, Andreas Abel <andreas.abel <at> ifi.lmu.de>wrote:
> 
> > +1 AMP
> > +1 MINIMAL
> > +1 Pointed in base
> >
> >
> > On 24.05.2013 03:39, John Lato wrote:
> >
> >> +1 for AMP (with or without DefaultSignatures)
> >> +1 for MINIMAL pragma
> >>
> >>
> >> On Fri, May 24, 2013 at 8:26 AM, Dan Burton <danburton.email <at> gmail.com
> >> <mailto:danburton.email <at> gmail.**com <danburton.email <at> gmail.com>>> wrote:
> >>
> >>     I think that removing return from the Monad class and making it an
> >>     alias of pure is the Right Thing to Do, but not yet. The proposal,
> >>     as it stands, is very tasteful about how little it breaks. Let's
> >>     keep `return = pure` on the back-burner for a while.
> >>     ______________________________**_________________
> >>     Libraries mailing list
> >>     Libraries <at> haskell.org <mailto:Libraries <at> haskell.org>
> >>     http://www.haskell.org/**mailman/listinfo/libraries<http://www.haskell.org/mailman/listinfo/libraries>
> >>
> >>
> >>
> >>
> >>
> >> ______________________________**_________________
> >> Libraries mailing list
> >> Libraries <at> haskell.org
> >> http://www.haskell.org/**mailman/listinfo/libraries<http://www.haskell.org/mailman/listinfo/libraries>
> >>
> >>
> >
> > --
> > Andreas Abel  <><      Du bist der geliebte Mensch.
> >
> > Theoretical Computer Science, University of Munich
> > Oettingenstr. 67, D-80538 Munich, GERMANY
> >
> > andreas.abel <at> ifi.lmu.de
> > http://www2.tcs.ifi.lmu.de/~**abel/ <http://www2.tcs.ifi.lmu.de/~abel/>
> >
> >
> > ______________________________**_________________
> > Libraries mailing list
> > Libraries <at> haskell.org
> > http://www.haskell.org/**mailman/listinfo/libraries<http://www.haskell.org/mailman/listinfo/libraries>
> >

> _______________________________________________
> Libraries mailing list
> Libraries <at> haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
Oliver Charles | 24 May 17:46 2013
Picon

2014: Pointed (was: 2014 Applicative => Monad proposal)

On 05/24/2013 04:28 PM, Roman Cheplyaka wrote:
> I completely agree with Edward here.
>
> * Edward Kmett <ekmett <at> gmail.com> [2013-05-24 11:20:51-0400]
>> For the record I'm actually -1 on including Pointed.
>>
>> My experience is that there are very few uses for the class that permit you
>> to reason about your code without one-off ad hoc reasoning based on the
>> particular instance you are given. Now, the Apply and Bind classes on the
>> other hand... =) Though, to be fair, I couldn't seriously propose including
>> either of those, either. Even I can't be bothered to instantiate them all
>> the time!
>>
>> -Edward
So maybe we should turn this around and ask those who were +1 on this 
specific item - why do you want Pointed?

For me, I've occasionally wanted a uniform interface to things like 
"Set.singleton", with the ability to switch that to lists because 
sometimes that makes things easier to play with in GHCi. Arguably a weak 
point, but that is what's tempted me with it before.

What are the other problems that Pointed solves?
- ocharles
Andreas Abel | 24 May 19:02 2013
Picon

Pointed [Re: 2014 Applicative => Monad proposal]

I do not use Pointed a lot, but a situation where it comes natural is 
when I want to emit elements into a collection f.  Then I need

   Pointed f    -- to emit a single element
   Monoid (f a) -- to join two collections

Using Applicative or Monad is overdoing it.

Maybe you have a better suggestion how to organize my task which I have 
not considered yet...

Cheers, Andreas

On 24.05.2013 17:28, Roman Cheplyaka wrote:
> I completely agree with Edward here.
>
> * Edward Kmett <ekmett <at> gmail.com> [2013-05-24 11:20:51-0400]
>> For the record I'm actually -1 on including Pointed.
>>
>> My experience is that there are very few uses for the class that permit you
>> to reason about your code without one-off ad hoc reasoning based on the
>> particular instance you are given. Now, the Apply and Bind classes on the
>> other hand... =) Though, to be fair, I couldn't seriously propose including
>> either of those, either. Even I can't be bothered to instantiate them all
>> the time!
>>
>> -Edward
>>
>>
>> On Fri, May 24, 2013 at 11:13 AM, Andreas Abel <andreas.abel <at> ifi.lmu.de>wrote:
>>
>>> +1 AMP
>>> +1 MINIMAL
>>> +1 Pointed in base

--

-- 
Andreas Abel  <><      Du bist der geliebte Mensch.

Theoretical Computer Science, University of Munich
Oettingenstr. 67, D-80538 Munich, GERMANY

andreas.abel <at> ifi.lmu.de
http://www2.tcs.ifi.lmu.de/~abel/
Anthony Cowley | 24 May 19:22 2013

Re: Pointed [Re: 2014 Applicative => Monad proposal]

On May 24, 2013, at 1:02 PM, Andreas Abel <andreas.abel <at> ifi.lmu.de> wrote:

> I do not use Pointed a lot, but a situation where it comes natural is when I want to emit elements into a
collection f.  Then I need
> 
>  Pointed f    -- to emit a single element
>  Monoid (f a) -- to join two collections
> 
> Using Applicative or Monad is overdoing it.
> 
> Maybe you have a better suggestion how to organize my task which I have not considered yet...
> 
> Cheers, Andreas

I hit exactly this need somewhat regularly. There was some discussion about it on IRC recently, and the
consensus was that there isn't anything quite right for this purpose in any commonly used package. 

Anthony

> 
> On 24.05.2013 17:28, Roman Cheplyaka wrote:
>> I completely agree with Edward here.
>> 
>> * Edward Kmett <ekmett <at> gmail.com> [2013-05-24 11:20:51-0400]
>>> For the record I'm actually -1 on including Pointed.
>>> 
>>> My experience is that there are very few uses for the class that permit you
>>> to reason about your code without one-off ad hoc reasoning based on the
>>> particular instance you are given. Now, the Apply and Bind classes on the
>>> other hand... =) Though, to be fair, I couldn't seriously propose including
>>> either of those, either. Even I can't be bothered to instantiate them all
>>> the time!
>>> 
>>> -Edward
>>> 
>>> 
>>> On Fri, May 24, 2013 at 11:13 AM, Andreas Abel <andreas.abel <at> ifi.lmu.de>wrote:
>>> 
>>>> +1 AMP
>>>> +1 MINIMAL
>>>> +1 Pointed in base
> 
> -- 
> Andreas Abel  <><      Du bist der geliebte Mensch.
> 
> Theoretical Computer Science, University of Munich
> Oettingenstr. 67, D-80538 Munich, GERMANY
> 
> andreas.abel <at> ifi.lmu.de
> http://www2.tcs.ifi.lmu.de/~abel/
> 
> _______________________________________________
> Libraries mailing list
> Libraries <at> haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
Edward A Kmett | 24 May 19:56 2013
Picon

Re: Pointed [Re: 2014 Applicative => Monad proposal]

This is precisely the situation I am referring to when I mention ad hoc casewise reasoning.

What laws say that 'foldMap point' does anything useful? Given just the type signature what reasoning can
you do?

Without knowing the particular instances involved, you get nothing.

With Set you get a glued together Set, but Maybe is going to try to smash together the elements under the Maybe
with some extra Semigr^H^H^H^H^H^HMonoid.

Pointed requires ad hoc reasoning for virtually every use case. The only law you can state for it is a free
theorem for its type.

On the other hand with classes like Apply or Bind you get access to lots of useful semigroup-like structures
you can still reason about in general, not in particular, including things that can't be made
Applicative/Monadic. (e.g. IntMap).

On May 24, 2013, at 1:02 PM, Andreas Abel <andreas.abel <at> ifi.lmu.de> wrote:

> I do not use Pointed a lot, but a situation where it comes natural is when I want to emit elements into a
collection f.  Then I need
> 
>  Pointed f    -- to emit a single element
>  Monoid (f a) -- to join two collections
> 
> Using Applicative or Monad is overdoing it.
> 
> Maybe you have a better suggestion how to organize my task which I have not considered yet...
> 
> Cheers, Andreas
> 
> On 24.05.2013 17:28, Roman Cheplyaka wrote:
>> I completely agree with Edward here.
>> 
>> * Edward Kmett <ekmett <at> gmail.com> [2013-05-24 11:20:51-0400]
>>> For the record I'm actually -1 on including Pointed.
>>> 
>>> My experience is that there are very few uses for the class that permit you
>>> to reason about your code without one-off ad hoc reasoning based on the
>>> particular instance you are given. Now, the Apply and Bind classes on the
>>> other hand... =) Though, to be fair, I couldn't seriously propose including
>>> either of those, either. Even I can't be bothered to instantiate them all
>>> the time!
>>> 
>>> -Edward
>>> 
>>> 
>>> On Fri, May 24, 2013 at 11:13 AM, Andreas Abel <andreas.abel <at> ifi.lmu.de>wrote:
>>> 
>>>> +1 AMP
>>>> +1 MINIMAL
>>>> +1 Pointed in base
> 
> -- 
> Andreas Abel  <><      Du bist der geliebte Mensch.
> 
> Theoretical Computer Science, University of Munich
> Oettingenstr. 67, D-80538 Munich, GERMANY
> 
> andreas.abel <at> ifi.lmu.de
> http://www2.tcs.ifi.lmu.de/~abel/
Casey McCann | 24 May 20:13 2013
Picon

Re: Pointed [Re: 2014 Applicative => Monad proposal]

On Fri, May 24, 2013 at 1:56 PM, Edward A Kmett <ekmett <at> gmail.com> wrote:
> This is precisely the situation I am referring to when I mention ad hoc casewise reasoning.
>
> What laws say that 'foldMap point' does anything useful? Given just the type signature what reasoning can
you do?
>
> Without knowing the particular instances involved, you get nothing.
>
> With Set you get a glued together Set, but Maybe is going to try to smash together the elements under the
Maybe with some extra Semigr^H^H^H^H^H^HMonoid.
>
> Pointed requires ad hoc reasoning for virtually every use case. The only law you can state for it is a free
theorem for its type.

It's sort of like a higher-kinded equivalent of Data.Default, with
roughly the same semantics. Just think of it as being like
QuickCheck's Arbitrary class, except with a single, pre-determined RNG
seed. Useful!

> On the other hand with classes like Apply or Bind you get access to lots of useful semigroup-like
structures you can still reason about in general, not in particular, including things that can't be made
Applicative/Monadic. (e.g. IntMap).

One example is that Bind would occasionally be handy for EDSLs that
don't permit lifting arbitrary values as a no-op. Incidentally,
desugaring do notation does not actually use return at all, if memory
serves me...

- C.
John Lato | 25 May 04:36 2013
Picon

Re: Pointed [Re: 2014 Applicative => Monad proposal]

> > On the other hand with classes like Apply or Bind you get access to lots of useful semigroup-like structures you can still reason about in general, not in particular, including things that can't be made Applicative/Monadic. (e.g. IntMap).
>
> One example is that Bind would occasionally be handy for EDSLs that
> don't permit lifting arbitrary values as a no-op. Incidentally,
> desugaring do notation does not actually use return at all, if memory
> serves me...

This strikes me as a very good reason for pointed.  Similar to how I'd like to see GArr included in ghc.

+1

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
John Wiegley | 25 May 08:44 2013

Re: Pointed [Re: 2014 Applicative => Monad proposal]

>>>>> John Lato <jwlato <at> gmail.com> writes:

>> One example is that Bind would occasionally be handy for EDSLs that
>> don't permit lifting arbitrary values as a no-op. Incidentally,
>> desugaring do notation does not actually use return at all, if memory
>> serves me...

> This strikes me as a very good reason for pointed.  Similar to how I'd like
> to see GArr included in ghc.

+1 to Pointed (and also Apply, Bind)

I would like to see Pointed/Apply/Bind make it in, alongside
Functor/Applicative/Monad.  Given the principle that it's always best to make
one's algorithms as general as possible (in order to limit the scope of what
must be reasoned about), having these three other classes would let us do more
of just that.

--

-- 
John Wiegley
FP Complete                         Haskell tools, training and consulting
http://fpcomplete.com               johnw on #haskell/irc.freenode.net

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Andreas Abel | 24 May 20:57 2013
Picon

Re: Pointed [Re: 2014 Applicative => Monad proposal]

You cannot expect much from point.  It could give you the empty
collection, a singleton, or multiple copies of the same element.

foldMap point could give you the unit of the monoid, if point is 
implemented "badly".  Tough luck.

Laws only arise with other operations, e.g. in Applicative or Monad.

However: I guess if you had something like "natural functors"

   Foundational, compositional (co)datatypes for higher-order 
logic—Category theory applied to theorem proving
Dmitriy Traytel, Andrei Popescu, and J. C. B. In 27th Annual IEEE 
Symposium on Logic in Computer Science (LICS 2012), pp. 596–605, IEEE, 
2012.

or "set-based functors" (Peter Aczel)

   A Predicative Strong Normalisation Proof for a λ-calculus with 
Interleaving Inductive Types
     Thorsten Altenkirch and Andreas Abel (2000)
     Types for Proofs and Programs, International Workshop, TYPES '99
     Lökeberg, Sweden, June 1999. LNCS 1956. ©Springer-Verlag

(good name lacking still) like

   class SetBased f where
     urelements :: f a -> [a]

then you would expect

   urelements (point a) = [a]

But unfortunately, for fs beyond collections, urelements is not computable:

   urelements :: (r -> a) -> [a]
   urelements f = "union x:r. f x"

Still this might serve as a (non-testable) specification of point.

You throwing in some thoughts,
Andreas

On 24.05.2013 19:56, Edward A Kmett wrote:
> This is precisely the situation I am referring to when I mention ad
> hoc casewise reasoning.
>
> What laws say that 'foldMap point' does anything useful? Given just
> the type signature what reasoning can you do?
>
> Without knowing the particular instances involved, you get nothing.
>
> With Set you get a glued together Set, but Maybe is going to try to
> smash together the elements under the Maybe with some extra
> Semigr^H^H^H^H^H^HMonoid.
>
> Pointed requires ad hoc reasoning for virtually every use case. The
> only law you can state for it is a free theorem for its type.
>
> On the other hand with classes like Apply or Bind you get access to
> lots of useful semigroup-like structures you can still reason about
> in general, not in particular, including things that can't be made
> Applicative/Monadic. (e.g. IntMap).
>
> On May 24, 2013, at 1:02 PM, Andreas Abel <andreas.abel <at> ifi.lmu.de>
> wrote:
>
>> I do not use Pointed a lot, but a situation where it comes natural
>> is when I want to emit elements into a collection f.  Then I need
>>
>> Pointed f    -- to emit a single element Monoid (f a) -- to join
>> two collections
>>
>> Using Applicative or Monad is overdoing it.
>>
>> Maybe you have a better suggestion how to organize my task which I
>> have not considered yet...
>>
>> Cheers, Andreas
>>
>> On 24.05.2013 17:28, Roman Cheplyaka wrote:
>>> I completely agree with Edward here.
>>>
>>> * Edward Kmett <ekmett <at> gmail.com> [2013-05-24 11:20:51-0400]
>>>> For the record I'm actually -1 on including Pointed.
>>>>
>>>> My experience is that there are very few uses for the class
>>>> that permit you to reason about your code without one-off ad
>>>> hoc reasoning based on the particular instance you are given.
>>>> Now, the Apply and Bind classes on the other hand... =) Though,
>>>> to be fair, I couldn't seriously propose including either of
>>>> those, either. Even I can't be bothered to instantiate them
>>>> all the time!
>>>>
>>>> -Edward
>>>>
>>>>
>>>> On Fri, May 24, 2013 at 11:13 AM, Andreas Abel
>>>> <andreas.abel <at> ifi.lmu.de>wrote:
>>>>
>>>>> +1 AMP +1 MINIMAL +1 Pointed in base
>>
>> -- Andreas Abel  <><      Du bist der geliebte Mensch.
>>
>> Theoretical Computer Science, University of Munich Oettingenstr.
>> 67, D-80538 Munich, GERMANY
>>
>> andreas.abel <at> ifi.lmu.de http://www2.tcs.ifi.lmu.de/~abel/
>

--

-- 
Andreas Abel  <><      Du bist der geliebte Mensch.

Theoretical Computer Science, University of Munich
Oettingenstr. 67, D-80538 Munich, GERMANY

andreas.abel <at> ifi.lmu.de
http://www2.tcs.ifi.lmu.de/~abel/

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Dan Doel | 24 May 19:59 2013
Picon

Re: Pointed [Re: 2014 Applicative => Monad proposal]

Where is Pointed supposed to live in the hierarchy? For instance, someone mentioned Set. But Set is not eligible to have a Functor instance.

So do we just have Pointed type functions that aren't necessarily Functors? And if they are Functors/Applicatives/Monads they're supposed to behave nicely?

And if not, then several collections are excluded from being Pointed, and I'm not entirely sure which collections you're using. Just many different sequence types?


On Fri, May 24, 2013 at 1:02 PM, Andreas Abel <andreas.abel <at> ifi.lmu.de> wrote:
I do not use Pointed a lot, but a situation where it comes natural is when I want to emit elements into a collection f.  Then I need

  Pointed f    -- to emit a single element
  Monoid (f a) -- to join two collections

Using Applicative or Monad is overdoing it.

Maybe you have a better suggestion how to organize my task which I have not considered yet...

Cheers, Andreas

On 24.05.2013 17:28, Roman Cheplyaka wrote:
I completely agree with Edward here.

* Edward Kmett <ekmett <at> gmail.com> [2013-05-24 11:20:51-0400]
For the record I'm actually -1 on including Pointed.

My experience is that there are very few uses for the class that permit you
to reason about your code without one-off ad hoc reasoning based on the
particular instance you are given. Now, the Apply and Bind classes on the
other hand... =) Though, to be fair, I couldn't seriously propose including
either of those, either. Even I can't be bothered to instantiate them all
the time!

-Edward


On Fri, May 24, 2013 at 11:13 AM, Andreas Abel <andreas.abel <at> ifi.lmu.de>wrote:

+1 AMP
+1 MINIMAL
+1 Pointed in base

--
Andreas Abel  <><      Du bist der geliebte Mensch.

Theoretical Computer Science, University of Munich
Oettingenstr. 67, D-80538 Munich, GERMANY

andreas.abel <at> ifi.lmu.de
http://www2.tcs.ifi.lmu.de/~abel/

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Andreas Abel | 24 May 20:15 2013
Picon

Re: Pointed [Re: 2014 Applicative => Monad proposal]

Pointed is a superclass of Applicative, taking the role of pure, but not 
related to Functor.  I do not see the problem.

On 24.05.2013 19:59, Dan Doel wrote:
> Where is Pointed supposed to live in the hierarchy? For instance,
> someone mentioned Set. But Set is not eligible to have a Functor instance.
>
> So do we just have Pointed type functions that aren't necessarily
> Functors? And if they are Functors/Applicatives/Monads they're supposed
> to behave nicely?
>
> And if not, then several collections are excluded from being Pointed,
> and I'm not entirely sure which collections you're using. Just many
> different sequence types?
>
>
> On Fri, May 24, 2013 at 1:02 PM, Andreas Abel <andreas.abel <at> ifi.lmu.de
> <mailto:andreas.abel <at> ifi.lmu.de>> wrote:
>
>     I do not use Pointed a lot, but a situation where it comes natural
>     is when I want to emit elements into a collection f.  Then I need
>
>        Pointed f    -- to emit a single element
>        Monoid (f a) -- to join two collections
>
>     Using Applicative or Monad is overdoing it.
>
>     Maybe you have a better suggestion how to organize my task which I
>     have not considered yet...
>
>     Cheers, Andreas
>
>     On 24.05.2013 17 <tel:24.05.2013%2017>:28, Roman Cheplyaka wrote:
>
>         I completely agree with Edward here.
>
>         * Edward Kmett <ekmett <at> gmail.com <mailto:ekmett <at> gmail.com>>
>         [2013-05-24 11:20:51-0400]
>
>             For the record I'm actually -1 on including Pointed.
>
>             My experience is that there are very few uses for the class
>             that permit you
>             to reason about your code without one-off ad hoc reasoning
>             based on the
>             particular instance you are given. Now, the Apply and Bind
>             classes on the
>             other hand... =) Though, to be fair, I couldn't seriously
>             propose including
>             either of those, either. Even I can't be bothered to
>             instantiate them all
>             the time!
>
>             -Edward
>
>
>             On Fri, May 24, 2013 at 11:13 AM, Andreas Abel
>             <andreas.abel <at> ifi.lmu.de
>             <mailto:andreas.abel <at> ifi.lmu.de>>__wrote:
>
>                 +1 AMP
>                 +1 MINIMAL
>                 +1 Pointed in base
>
>
>     --
>     Andreas Abel  <><      Du bist der geliebte Mensch.
>
>     Theoretical Computer Science, University of Munich
>     Oettingenstr. 67, D-80538 Munich, GERMANY
>
>     andreas.abel <at> ifi.lmu.de <mailto:andreas.abel <at> ifi.lmu.de>
>     http://www2.tcs.ifi.lmu.de/~__abel/ <http://www2.tcs.ifi.lmu.de/~abel/>
>
>     _________________________________________________
>     Libraries mailing list
>     Libraries <at> haskell.org <mailto:Libraries <at> haskell.org>
>     http://www.haskell.org/__mailman/listinfo/libraries
>     <http://www.haskell.org/mailman/listinfo/libraries>
>
>

--

-- 
Andreas Abel  <><      Du bist der geliebte Mensch.

Theoretical Computer Science, University of Munich
Oettingenstr. 67, D-80538 Munich, GERMANY

andreas.abel <at> ifi.lmu.de
http://www2.tcs.ifi.lmu.de/~abel/
Dan Doel | 25 May 17:33 2013
Picon

Re: Pointed [Re: 2014 Applicative => Monad proposal]

On Fri, May 24, 2013 at 2:15 PM, Andreas Abel <andreas.abel <at> ifi.lmu.de> wrote:
Pointed is a superclass of Applicative, taking the role of pure, but not related to Functor.  I do not see the problem.

The problem is: what is a Pointed? It's just anything with kind * -> * for which you can write a function with that type. Is the following a good definition, for instance?

    newtype Foo a = Foo ((a -> a -> a) -> a -> a)

    instance Pointed Foo where
      point x = Foo $ \m -> m x

How about this:

    newtype Bar r a = Bar (a -> r)

    instance Monoid m => Pointed (Bar m) where
      point _ = Bar $ const mempty

(Bar m is even a monoid for monoids m).

In particular...

John Wiegley wrote:
> (in order to limit the scope of what must be reasoned about)

Pointed is pretty bad for this. Or, maybe, it's good: there's nothing to reason about, because there's nothing you can reason about. It just does _something_ unspecified. Hopefully something that is good for combining with some other type class.

I've reluctantly come around to the Apply/Bind classes (despite them having bad names), because they actually follow the way people typically build up structure in algebra. Rarely do you see people defining 'a monoid is a pointed set equipped with an associative binary operation that uses the point as an identity.' It's much more likely that you see, 'a monoid is a semigroup with an identity for the binary operation.' I suspect that's even how many people would like to see the hierarchy at this point: Semigroup m => Monoid m. And not Default m => Monoid m, because Default is just ad-hoc nonsense (even if it's sometimes useful).

To answer your original question, perhaps a somewhat better way of characterizing the problem is probably talking about 'monoids m over type a'. Perhaps something like:

    class Monoid m => MonoidOver a m | m -> a where
      embed :: a -> m

which expresses that m is expected to be generated (as a monoid) by a in some way. Then maybe you can say something about how it interacts with the Monoid operations, which seems preferable to me to, "the operation of this class does anything, except if the type is also a monoid, or if it's also a monad...."

Anyhow, I'm -1 on Pointed, in case anyone couldn't tell.

-- Dan
_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Andreas Abel | 25 May 23:52 2013
Picon

Re: Pointed [Re: 2014 Applicative => Monad proposal]

Pointed f  alone does not give you any guarantees, you cannot exclude 
weird definitions like the one given by you or just

   point a = undefined

which is even worse, because it does not even give you non-emptyness of 
(f a).

But there are many useful type classes that cannot give you guarantees 
by themselves.  Consider Show and Read (used as printer and parser for 
abstract syntax).  Nothing prevents you to define show to print the 
empty string or Nietzsche quotes.  The defect becomes apparant only in 
the presence of Read, when laws like

    read . show == id

fail.  I don't suppose that every type class must unfold its full 
meaning by itself.

Thanks for suggesting MonoidOver, but I do not see any more laws coming 
from that than from Pointed + Monoid.  As long as you cannot take apart 
a monoid element into its atoms, you cannot state that embed does what 
you want.

Anyway, I think Pointed is useful, but its uses are not so frequent that 
it must be in base.  It is very little work to define the class and the 
instances one needs, so I can continue to do so if I need it.

On the other hand, in category theory Pointed is a standard notion, so 
it would make sense to push this piece of vocabulary.  Also, I see the 
singleton list constructor (:[]) quite often, and "point" would be more 
readable than this.

Yet, it seems that there is no majority for Pointed, so discussing this 
much longer is pointless.

On 25.05.13 5:33 PM, Dan Doel wrote:
> On Fri, May 24, 2013 at 2:15 PM, Andreas Abel <andreas.abel <at> ifi.lmu.de
> <mailto:andreas.abel <at> ifi.lmu.de>> wrote:
>
>     Pointed is a superclass of Applicative, taking the role of pure, but
>     not related to Functor.  I do not see the problem.
>
>
> The problem is: what is a Pointed? It's just anything with kind * -> *
> for which you can write a function with that type. Is the following a
> good definition, for instance?
>
>      newtype Foo a = Foo ((a -> a -> a) -> a -> a)
>
>      instance Pointed Foo where
>        point x = Foo $ \m -> m x
>
> How about this:
>
>      newtype Bar r a = Bar (a -> r)
>
>      instance Monoid m => Pointed (Bar m) where
>        point _ = Bar $ const mempty
>
> (Bar m is even a monoid for monoids m).
>
> In particular...
>
> John Wiegley wrote:
>  > (in order to limit the scope of what must be reasoned about)
>
> Pointed is pretty bad for this. Or, maybe, it's good: there's nothing to
> reason about, because there's nothing you can reason about. It just does
> _something_ unspecified. Hopefully something that is good for combining
> with some other type class.
>
> I've reluctantly come around to the Apply/Bind classes (despite them
> having bad names), because they actually follow the way people typically
> build up structure in algebra. Rarely do you see people defining 'a
> monoid is a pointed set equipped with an associative binary operation
> that uses the point as an identity.' It's much more likely that you see,
> 'a monoid is a semigroup with an identity for the binary operation.' I
> suspect that's even how many people would like to see the hierarchy at
> this point: Semigroup m => Monoid m. And not Default m => Monoid m,
> because Default is just ad-hoc nonsense (even if it's sometimes useful).
>
> To answer your original question, perhaps a somewhat better way of
> characterizing the problem is probably talking about 'monoids m over
> type a'. Perhaps something like:
>
>      class Monoid m => MonoidOver a m | m -> a where
>        embed :: a -> m
>
> which expresses that m is expected to be generated (as a monoid) by a in
> some way. Then maybe you can say something about how it interacts with
> the Monoid operations, which seems preferable to me to, "the operation
> of this class does anything, except if the type is also a monoid, or if
> it's also a monad...."
>
> Anyhow, I'm -1 on Pointed, in case anyone couldn't tell.
>
> -- Dan

--

-- 
Andreas Abel  <><      Du bist der geliebte Mensch.

Theoretical Computer Science, University of Munich
Oettingenstr. 67, D-80538 Munich, GERMANY

andreas.abel <at> ifi.lmu.de
http://www2.tcs.ifi.lmu.de/~abel/
Carter Schonwald | 26 May 00:23 2013
Picon

Re: Pointed [Re: 2014 Applicative => Monad proposal]

the read . show example is something of a red herring, which could be solved with explicit type annotations, namely

id ::Show a, Read a => a -> a
id x = read $ show x 

(or some variant of read that has a type like 
read :: String -> Proxy t -> t, so that the type selection is made explicit in the API)

the ill-definedness semanticaly for pointed doesn't see to be simply of the "a type annotation is missing" sort.



On Sat, May 25, 2013 at 5:52 PM, Andreas Abel <andreas.abel <at> ifi.lmu.de> wrote:
Pointed f  alone does not give you any guarantees, you cannot exclude weird definitions like the one given by you or just

  point a = undefined

which is even worse, because it does not even give you non-emptyness of (f a).

But there are many useful type classes that cannot give you guarantees by themselves.  Consider Show and Read (used as printer and parser for abstract syntax).  Nothing prevents you to define show to print the empty string or Nietzsche quotes.  The defect becomes apparant only in the presence of Read, when laws like

   read . show == id

fail.  I don't suppose that every type class must unfold its full meaning by itself.

Thanks for suggesting MonoidOver, but I do not see any more laws coming from that than from Pointed + Monoid.  As long as you cannot take apart a monoid element into its atoms, you cannot state that embed does what you want.

Anyway, I think Pointed is useful, but its uses are not so frequent that it must be in base.  It is very little work to define the class and the instances one needs, so I can continue to do so if I need it.

On the other hand, in category theory Pointed is a standard notion, so it would make sense to push this piece of vocabulary.  Also, I see the singleton list constructor (:[]) quite often, and "point" would be more readable than this.

Yet, it seems that there is no majority for Pointed, so discussing this much longer is pointless.


On 25.05.13 5:33 PM, Dan Doel wrote:
On Fri, May 24, 2013 at 2:15 PM, Andreas Abel <andreas.abel <at> ifi.lmu.de
<mailto:andreas.abel <at> ifi.lmu.de>> wrote:

    Pointed is a superclass of Applicative, taking the role of pure, but
    not related to Functor.  I do not see the problem.


The problem is: what is a Pointed? It's just anything with kind * -> *
for which you can write a function with that type. Is the following a
good definition, for instance?

     newtype Foo a = Foo ((a -> a -> a) -> a -> a)

     instance Pointed Foo where
       point x = Foo $ \m -> m x

How about this:

     newtype Bar r a = Bar (a -> r)

     instance Monoid m => Pointed (Bar m) where
       point _ = Bar $ const mempty

(Bar m is even a monoid for monoids m).

In particular...

John Wiegley wrote:
 > (in order to limit the scope of what must be reasoned about)

Pointed is pretty bad for this. Or, maybe, it's good: there's nothing to
reason about, because there's nothing you can reason about. It just does
_something_ unspecified. Hopefully something that is good for combining
with some other type class.

I've reluctantly come around to the Apply/Bind classes (despite them
having bad names), because they actually follow the way people typically
build up structure in algebra. Rarely do you see people defining 'a
monoid is a pointed set equipped with an associative binary operation
that uses the point as an identity.' It's much more likely that you see,
'a monoid is a semigroup with an identity for the binary operation.' I
suspect that's even how many people would like to see the hierarchy at
this point: Semigroup m => Monoid m. And not Default m => Monoid m,
because Default is just ad-hoc nonsense (even if it's sometimes useful).

To answer your original question, perhaps a somewhat better way of
characterizing the problem is probably talking about 'monoids m over
type a'. Perhaps something like:

     class Monoid m => MonoidOver a m | m -> a where
       embed :: a -> m

which expresses that m is expected to be generated (as a monoid) by a in
some way. Then maybe you can say something about how it interacts with
the Monoid operations, which seems preferable to me to, "the operation
of this class does anything, except if the type is also a monoid, or if
it's also a monad...."

Anyhow, I'm -1 on Pointed, in case anyone couldn't tell.

-- Dan

--
Andreas Abel  <><      Du bist der geliebte Mensch.

Theoretical Computer Science, University of Munich
Oettingenstr. 67, D-80538 Munich, GERMANY

andreas.abel <at> ifi.lmu.de
http://www2.tcs.ifi.lmu.de/~abel/

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Daniel Peebles | 26 May 17:32 2013
Picon

Re: Pointed [Re: 2014 Applicative => Monad proposal]

The objection isn't that Pointed has no self-contained laws or that typeclasses can't have laws relating them to other classes, but that the only law relating Pointed to another class (Functor, saying fmap f . pure = pure . f) is provided by parametricity anyway.

I don't think undefined adds much to the discussion. We're saying that even in Agda, Pointed (over the Set-like Agda category) doesn't really abstract over things you want to abstract over. The fact that Set.singleton doesn't require an ordering is almost an implementation accident. How many other things are Pointed in a "meaningful" way without being more as well? And what do you define as meaningful, to exclude Dan's ridiculous instances?


On Sat, May 25, 2013 at 5:52 PM, Andreas Abel <andreas.abel <at> ifi.lmu.de> wrote:
Pointed f  alone does not give you any guarantees, you cannot exclude weird definitions like the one given by you or just

  point a = undefined

which is even worse, because it does not even give you non-emptyness of (f a).

But there are many useful type classes that cannot give you guarantees by themselves.  Consider Show and Read (used as printer and parser for abstract syntax).  Nothing prevents you to define show to print the empty string or Nietzsche quotes.  The defect becomes apparant only in the presence of Read, when laws like

   read . show == id

fail.  I don't suppose that every type class must unfold its full meaning by itself.

Thanks for suggesting MonoidOver, but I do not see any more laws coming from that than from Pointed + Monoid.  As long as you cannot take apart a monoid element into its atoms, you cannot state that embed does what you want.

Anyway, I think Pointed is useful, but its uses are not so frequent that it must be in base.  It is very little work to define the class and the instances one needs, so I can continue to do so if I need it.

On the other hand, in category theory Pointed is a standard notion, so it would make sense to push this piece of vocabulary.  Also, I see the singleton list constructor (:[]) quite often, and "point" would be more readable than this.

Yet, it seems that there is no majority for Pointed, so discussing this much longer is pointless.


On 25.05.13 5:33 PM, Dan Doel wrote:
On Fri, May 24, 2013 at 2:15 PM, Andreas Abel <andreas.abel <at> ifi.lmu.de
<mailto:andreas.abel <at> ifi.lmu.de>> wrote:

    Pointed is a superclass of Applicative, taking the role of pure, but
    not related to Functor.  I do not see the problem.


The problem is: what is a Pointed? It's just anything with kind * -> *
for which you can write a function with that type. Is the following a
good definition, for instance?

     newtype Foo a = Foo ((a -> a -> a) -> a -> a)

     instance Pointed Foo where
       point x = Foo $ \m -> m x

How about this:

     newtype Bar r a = Bar (a -> r)

     instance Monoid m => Pointed (Bar m) where
       point _ = Bar $ const mempty

(Bar m is even a monoid for monoids m).

In particular...

John Wiegley wrote:
 > (in order to limit the scope of what must be reasoned about)

Pointed is pretty bad for this. Or, maybe, it's good: there's nothing to
reason about, because there's nothing you can reason about. It just does
_something_ unspecified. Hopefully something that is good for combining
with some other type class.

I've reluctantly come around to the Apply/Bind classes (despite them
having bad names), because they actually follow the way people typically
build up structure in algebra. Rarely do you see people defining 'a
monoid is a pointed set equipped with an associative binary operation
that uses the point as an identity.' It's much more likely that you see,
'a monoid is a semigroup with an identity for the binary operation.' I
suspect that's even how many people would like to see the hierarchy at
this point: Semigroup m => Monoid m. And not Default m => Monoid m,
because Default is just ad-hoc nonsense (even if it's sometimes useful).

To answer your original question, perhaps a somewhat better way of
characterizing the problem is probably talking about 'monoids m over
type a'. Perhaps something like:

     class Monoid m => MonoidOver a m | m -> a where
       embed :: a -> m

which expresses that m is expected to be generated (as a monoid) by a in
some way. Then maybe you can say something about how it interacts with
the Monoid operations, which seems preferable to me to, "the operation
of this class does anything, except if the type is also a monoid, or if
it's also a monad...."

Anyhow, I'm -1 on Pointed, in case anyone couldn't tell.

-- Dan

--
Andreas Abel  <><      Du bist der geliebte Mensch.

Theoretical Computer Science, University of Munich
Oettingenstr. 67, D-80538 Munich, GERMANY

andreas.abel <at> ifi.lmu.de
http://www2.tcs.ifi.lmu.de/~abel/

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
John Wiegley | 26 May 02:15 2013

Re: Pointed [Re: 2014 Applicative => Monad proposal]

>>>>> Dan Doel <dan.doel <at> gmail.com> writes:

> Pointed is pretty bad for this. Or, maybe, it's good: there's nothing to
> reason about, because there's nothing you can reason about. It just does
> _something_ unspecified. Hopefully something that is good for combining with
> some other type class.

Your argument here convinces me.  Since Pointed doesn't come with laws, it's
not as valuable a tool for abstraction as I had thought.

> Anyhow, I'm -1 on Pointed, in case anyone couldn't tell.

Changing to -1.

--

-- 
John Wiegley
FP Complete                         Haskell tools, training and consulting
http://fpcomplete.com               johnw on #haskell/irc.freenode.net
Petr Pudlák | 26 May 09:57 2013
Picon

Re: Pointed [Re: 2014 Applicative => Monad proposal]

Dne 25.5.2013 17:33, Dan Doel napsal(a):

On Fri, May 24, 2013 at 2:15 PM, Andreas Abel <andreas.abel <at> ifi.lmu.de> wrote:

[...]
Pointed is pretty bad for this. Or, maybe, it's good: there's nothing to reason about, because there's nothing you can reason about. It just does _something_ unspecified. Hopefully something that is good for combining with some other type class.

-1 on Pointed.


I've reluctantly come around to the Apply/Bind classes (despite them having bad names), because they actually follow the way people typically build up structure in algebra. Rarely do you see people defining 'a monoid is a pointed set equipped with an associative binary operation that uses the point as an identity.' It's much more likely that you see, 'a monoid is a semigroup with an identity for the binary operation.' I suspect that's even how many people would like to see the hierarchy at this point: Semigroup m => Monoid m. And not Default m => Monoid m, because Default is just ad-hoc nonsense (even if it's sometimes useful).

To answer your original question, perhaps a somewhat better way of characterizing the problem is probably talking about 'monoids m over type a'. Perhaps something like:

    class Monoid m => MonoidOver a m | m -> a where
      embed :: a -> m

which expresses that m is expected to be generated (as a monoid) by a in some way. Then maybe you can say something about how it interacts with the Monoid operations, which seems preferable to me to, "the operation of this class does anything, except if the type is also a monoid, or if it's also a monad...."

I think you hit the nail on the head here. The only places when I missed something like Pointed were when I wanted to abstract building some kind of collection (Set / [] / Seq / ...). They're all monoids, but you need some way how to construct singleton collections. Having MonoidOver would solve precisely this problem. I'd certainly prefer something like this over Pointed.

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Shachaf Ben-Kiki | 26 May 10:22 2013
Picon

Re: Pointed [Re: 2014 Applicative => Monad proposal]

On Sun, May 26, 2013 at 3:57 AM, Petr Pudlák <petr.mvd <at> gmail.com> wrote:
>
> I think you hit the nail on the head here. The only places when I missed
> something like Pointed were when I wanted to abstract building some kind of
> collection (Set / [] / Seq / ...). They're all monoids, but you need some
> way how to construct singleton collections. Having MonoidOver would solve
> precisely this problem. I'd certainly prefer something like this over
> Pointed.
>
>

One point in Pointed's favor is that it lets one express "affine
traversals" -- that is, a function with a type like "Pointed f => (a
-> f b) -> T a -> f (T b)". This is like a traversal -- traverse ::
Applicative f => (a -> f b) -> T a -> f (T b) for some Traversable T
-- but guarantees that it traverses either 0 or 1 elements, rather
than 0-or-more. With a Pointed superclass for Applicative an affine
traversal can automatically be used as a regular traversal. I don't
know that this is worth adding a superclass for -- certainly it should
be a separate proposal -- but it's useful for some code, e.g. lens, to
get stronger type guarantees.

    Shachaf
Gabriel Gonzalez | 25 May 17:18 2013
Picon

Re: Pointed [Re: 2014 Applicative => Monad proposal]

-1 on Pointed/Apply/Bind

These are of very limited utility and we don't need these three 
instances cluttering up instance lists and distracting the user from 
more important instances.

If you're going to make things less monomorphic then you need to be more 
judicious about the type classes you choose.
harry | 3 Jun 20:45 2013
Picon

Re: 2014 Applicative => Monad proposal

+1, if it isn't too late to vote
Nikita Volkov | 3 Jun 21:32 2013
Picon

Re: 2014 Applicative => Monad proposal

Yeah +1 me too.

On Jun 3, 2013, at 10:45 PM, harry <voldermort <at> hotmail.com> wrote:

> +1, if it isn't too late to vote
> 
> 
> _______________________________________________
> Libraries mailing list
> Libraries <at> haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
Bardur Arantsson | 24 May 04:41 2013
Picon

Re: 2014 Applicative => Monad proposal

On 05/23/2013 09:39 PM, David Luposchainsky wrote:
> Hello libraries,
> 

+1, AMP
Carter Schonwald | 24 May 05:22 2013
Picon

Re: 2014 Applicative => Monad proposal

+1 


On Thu, May 23, 2013 at 10:41 PM, Bardur Arantsson <spam <at> scientician.net> wrote:
On 05/23/2013 09:39 PM, David Luposchainsky wrote:
> Hello libraries,
>

+1, AMP



_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Ganesh Sittampalam | 24 May 07:59 2013
Picon

Re: 2014 Applicative => Monad proposal

On 23/05/2013 20:39, David Luposchainsky wrote:

> - Don't break compatibility
> - Apply it gently
> 
> - Applicative m => Monad m
> - Applicative into Prelude (and therefore into the Report)
> - (Alternative m, Monad m) => MonadPlus m

+1

> - Promote `join` into the Monad typeclass

-1

Typeclasses with cyclic defaults are too fragile at the moment. Let's
sort that out *before* adopting a change that increases the number of
such typeclasses.

Ganesh
Petr Pudlák | 24 May 09:13 2013
Picon

Re: 2014 Applicative => Monad proposal

> On 23/05/2013 20:39, David Luposchainsky wrote:
>
>> - Don't break compatibility
>> - Apply it gently
>>
>> - Applicative m => Monad m
>> - Applicative into Prelude (and therefore into the Report)
>> - (Alternative m, Monad m) => MonadPlus m
+1
>> - Promote `join` into the Monad typeclass
>
+1 if it goes together with the MINIMAL pragma,
-1 otherwise.
David Luposchainsky | 17 Jun 14:22 2013

Re: 2014 Applicative => Monad proposal

Hey,

discussion about the AMP is long over, but I wanted to give the few
people that had some issues with it on IRC the time to write their
objections up and post them here. It seems like that's never going to
happen, so:

*This is the last call to object to the AMP, which has been unanimously
upvoted on the mailing lists.*
(There remains the circular join/>>= issue, but that's probably solved
until phase 3 - the actual implementation - is reached.)

As a reminder, phase one includes adding deprecation messages for Monads
without Applicative/Functor instances and custom usage of join/<*>/pure,
as well as fixing these warnings in GHC's source.

Unless something comes up, I'll post the tickets to Trac by the end of
the week.

Thanks for everyone's participation,
David
Roman Cheplyaka | 24 May 10:07 2013

Re: 2014 Applicative => Monad proposal

+1

* David Luposchainsky <dluposchainsky <at> googlemail.com> [2013-05-23 21:39:17+0200]
> Hello libraries,
> 
> it's on! Time to tackle the Applicative-Monad issue, hopefully once and
> for all. Over the last couple of weeks I've looked through previous
> proposals, asked #haskell about their opinions, and compiled it all into
> one file that sums up what I made of that. It's a bit long for an email
> and uses markdown, so I'll just provide links at the end of this mail
> instead of pasting it in here. In there, the whole thing and how to
> approach it is explained in more detail. Here's an abstract of what it
> the proposal consists of:
> 
> 
> - Don't break compatibility
> - Apply it gently
> 
> - Applicative m => Monad m
> - Applicative into Prelude (and therefore into the Report)
> - (Alternative m, Monad m) => MonadPlus m
> - Promote `join` into the Monad typeclass
> 
> 
> Let's make this happen! I'm going to give a ballpark discussion period
> of four weeks, but since I can imagine this discussion could become
> quite complex we shouldn't take it too serious. I'll summarize what's
> been going on periodically though.
> 
> David
> 
> 
> 
> Links:
> 
> The proposal text on Github (link fixed, sorry for the deadlink yesterday):
> https://github.com/quchen/articles/blob/master/applicative_monad.md
> (This file is subject to changes, depending on how this discussion goes.
> I'll try to make it reflect the current consensus.)
> 
> And just in case Github silentbans me again for submitting too many
> edits to my Gist (grrr), here's a copy of the file on HPaste as backup:
> http://hpaste.org/88423
> 
> _______________________________________________
> Libraries mailing list
> Libraries <at> haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
wren ng thornton | 24 May 23:59 2013

Re: 2014 Applicative => Monad proposal

On 5/24/13 11:20 AM, Edward Kmett wrote:
> For the record I'm actually -1 on including Pointed.
>
> My experience is that there are very few uses for the class that permit you
> to reason about your code without one-off ad hoc reasoning based on the
> particular instance you are given. Now, the Apply and Bind classes on the
> other hand... =) Though, to be fair, I couldn't seriously propose including
> either of those, either. Even I can't be bothered to instantiate them all
> the time!

FWIW, as things stand, I'm also -1 for Pointed. Pointed doesn't really
have much meaning on its own, so I think it's more helpful to invert the
hierarchy as Kmett has done and have Apply/Bind classes as the
generalization of Applicative/Monad.

More to the point, the Pointed proposal doesn't meet the AMP goals of
gentility and compatibility. And the controversy renders it dubious for
inclusion in the proposal to make a unified compatibility-breaking change
to clean up the long-standing complaints.

--

-- 
Live well,
~wren
David Luposchainsky | 25 May 00:20 2013

Re: 2014 Applicative => Monad proposal

On 2013-05-24 23:59, wren ng thornton wrote:
> FWIW, as things stand, I'm also -1 for Pointed. Pointed doesn't really
> have much meaning on its own, so I think it's more helpful to invert the
> hierarchy as Kmett has done and have Apply/Bind classes as the
> generalization of Applicative/Monad.
> 
> More to the point, the Pointed proposal doesn't meet the AMP goals of
> gentility and compatibility. And the controversy renders it dubious for
> inclusion in the proposal to make a unified compatibility-breaking change
> to clean up the long-standing complaints.

I'd also vote -1 for Pointed. For one Applicative and Monad are widely
used, can't say that of Pointed. Compatibility is another big thing: the
AMP connects things that are already there, while Pointed would mean
introducing the typeclass in Base in the first place.

On the other hand, I think the AMP can also serve as a model for similar
proposals in the future. Should it turn out in five years that Pointed
is amazing and we all need it, its inclusion won't be much different
from the AMP right now, except that we'll all know what to expect
beforehand.

David
Mario Blažević | 25 May 05:30 2013
Picon

Re: 2014 Applicative => Monad proposal

+1 AMP

     Would GHC report a warning for every definition of the return 
method, in anticipation of the time when it becomes synonymous with 
pure? Backward compatibility aside, does anybody actually want to 
preserve return as a method of the Monad class? The only use case I can 
think of is having return fail for some arguments.
Felipe Almeida Lessa | 27 May 22:58 2013
Picon

Re: 2014 Applicative => Monad proposal

+1 AMP.

Very well written, thanks! =)

On Thu, May 23, 2013 at 4:39 PM, David Luposchainsky
<dluposchainsky <at> googlemail.com> wrote:
> Hello libraries,
>
> it's on! Time to tackle the Applicative-Monad issue, hopefully once and
> for all. Over the last couple of weeks I've looked through previous
> proposals, asked #haskell about their opinions, and compiled it all into
> one file that sums up what I made of that. It's a bit long for an email
> and uses markdown, so I'll just provide links at the end of this mail
> instead of pasting it in here. In there, the whole thing and how to
> approach it is explained in more detail. Here's an abstract of what it
> the proposal consists of:
>
>
> - Don't break compatibility
> - Apply it gently
>
> - Applicative m => Monad m
> - Applicative into Prelude (and therefore into the Report)
> - (Alternative m, Monad m) => MonadPlus m
> - Promote `join` into the Monad typeclass
>
>
> Let's make this happen! I'm going to give a ballpark discussion period
> of four weeks, but since I can imagine this discussion could become
> quite complex we shouldn't take it too serious. I'll summarize what's
> been going on periodically though.
>
> David
>
>
>
> Links:
>
> The proposal text on Github (link fixed, sorry for the deadlink yesterday):
> https://github.com/quchen/articles/blob/master/applicative_monad.md
> (This file is subject to changes, depending on how this discussion goes.
> I'll try to make it reflect the current consensus.)
>
> And just in case Github silentbans me again for submitting too many
> edits to my Gist (grrr), here's a copy of the file on HPaste as backup:
> http://hpaste.org/88423
>
> _______________________________________________
> Libraries mailing list
> Libraries <at> haskell.org
> http://www.haskell.org/mailman/listinfo/libraries

--

-- 
Felipe.
David Luposchainsky | 30 May 23:51 2013

Re: 2014 Applicative => Monad proposal

Hey everyone,

here's a short summary of what's happened during the AMP's first week:

- Adding `join` to the Monad typeclass introduces a cyclic dependency,
  leading to an infinite loop if the function definitions are
  forgotten. Until this is solved, the `join` part of the proposal may
  not be a good idea.
  Ticket #7633 solves this problem by introducing compiler warnings if
  the minimal complete definition is not met. Looking at the Trac page,
  it's probably going to be in HEAD quite soon.

- Apart from the `join` issue, everyone seems to be in favor of the
  AMP as proposed. (+19/-0 according to Ben's writeup)

- A `Pointed` typeclass discussion emerged from the AMP thread with
  mixed opinions. If necessary, this should be made a separate
  proposal.

- I was asked about MonadFail by multiple people via email. Again, the
  reason this is not considered in the AMP is that it is orthogonal to
  the proposed changes; the only similarity is that it changes things
  in the same typeclass we're already editing.

So long,

David
Conal Elliott | 5 Jun 18:00 2013
Picon

Re: 2014 Applicative => Monad proposal

+1. Looks great. Thanks!


On Thu, May 23, 2013 at 12:39 PM, David Luposchainsky <dluposchainsky <at> googlemail.com> wrote:
Hello libraries,

it's on! Time to tackle the Applicative-Monad issue, hopefully once and
for all. Over the last couple of weeks I've looked through previous
proposals, asked #haskell about their opinions, and compiled it all into
one file that sums up what I made of that. It's a bit long for an email
and uses markdown, so I'll just provide links at the end of this mail
instead of pasting it in here. In there, the whole thing and how to
approach it is explained in more detail. Here's an abstract of what it
the proposal consists of:


- Don't break compatibility
- Apply it gently

- Applicative m => Monad m
- Applicative into Prelude (and therefore into the Report)
- (Alternative m, Monad m) => MonadPlus m
- Promote `join` into the Monad typeclass


Let's make this happen! I'm going to give a ballpark discussion period
of four weeks, but since I can imagine this discussion could become
quite complex we shouldn't take it too serious. I'll summarize what's
been going on periodically though.

David



Links:

The proposal text on Github (link fixed, sorry for the deadlink yesterday):
https://github.com/quchen/articles/blob/master/applicative_monad.md
(This file is subject to changes, depending on how this discussion goes.
I'll try to make it reflect the current consensus.)

And just in case Github silentbans me again for submitting too many
edits to my Gist (grrr), here's a copy of the file on HPaste as backup:
http://hpaste.org/88423

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Daniel Díaz Casanueva | 5 Jun 20:08 2013
Picon

Re: 2014 Applicative => Monad proposal

Hi there!

I am excited about this proposal, and I really hopes it will be performed. I have been following the discussion for a long time, always perceiving that Applicative as a superclass of Monad is the right thing to do. As a consequence, Functor will also be a superclass of Monad. This changes may affect my code, but I will be glad to make any changes.

There is a wiki page related [1] that should be updated.

Also, I am wondering if our agreement to implement this proposal would imply an Applicative class being included in a future Haskell Report.

Cheers,
Daniel Díaz.

--

[1] HaskellWiki: Functor-Applicative-Monad Proposal - http://www.haskell.org/haskellwiki/Functor-Applicative-Monad_Proposal


On Wed, Jun 5, 2013 at 6:00 PM, Conal Elliott <conal <at> conal.net> wrote:
+1. Looks great. Thanks!


On Thu, May 23, 2013 at 12:39 PM, David Luposchainsky <dluposchainsky <at> googlemail.com> wrote:
Hello libraries,

it's on! Time to tackle the Applicative-Monad issue, hopefully once and
for all. Over the last couple of weeks I've looked through previous
proposals, asked #haskell about their opinions, and compiled it all into
one file that sums up what I made of that. It's a bit long for an email
and uses markdown, so I'll just provide links at the end of this mail
instead of pasting it in here. In there, the whole thing and how to
approach it is explained in more detail. Here's an abstract of what it
the proposal consists of:


- Don't break compatibility
- Apply it gently

- Applicative m => Monad m
- Applicative into Prelude (and therefore into the Report)
- (Alternative m, Monad m) => MonadPlus m
- Promote `join` into the Monad typeclass


Let's make this happen! I'm going to give a ballpark discussion period
of four weeks, but since I can imagine this discussion could become
quite complex we shouldn't take it too serious. I'll summarize what's
been going on periodically though.

David



Links:

The proposal text on Github (link fixed, sorry for the deadlink yesterday):
https://github.com/quchen/articles/blob/master/applicative_monad.md
(This file is subject to changes, depending on how this discussion goes.
I'll try to make it reflect the current consensus.)

And just in case Github silentbans me again for submitting too many
edits to my Gist (grrr), here's a copy of the file on HPaste as backup:
http://hpaste.org/88423

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
David Luposchainsky | 5 Jun 20:54 2013

Re: 2014 Applicative => Monad proposal

On 2013-06-05 20:08, Daniel Díaz Casanueva wrote:
> I am excited about this proposal, and I really hopes it will be 
> performed. I have been following the discussion for a long time,
> always perceiving that Applicative as a superclass of Monad is the
> right thing to do. As a consequence, Functor will also be a
> superclass of Monad. This changes may affect my code, but I will be
> glad to make any changes.

If your code ...
- does not use the names join, <*> or pure outside of their
  Applicative/Monad context
- includes Applicative instances for all Monads
... there is nothing to change. Boring, I know.

> Also, I am wondering if our agreement to implement this proposal
> would imply an Applicative class being included in a future Haskell
> Report.

The libraries mailing list does not decide changes to the Report. That
said, the long term plan is changing the Report, preferrably in the next
iteration, and getting GHC and Hackage ready for it is the most
important step towards it. Although when these changes are made I see no
reason not to make the AMP official, it remains speculation at this point.

David

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
David Luposchainsky | 21 Jun 13:23 2013

Re: 2014 Applicative => Monad proposal

Hello everyone,

as announced a couple of days ago, the AMP was quite a success, and I'm
really happy no serious unforseen issues came up. I'm closing the
discussion now, thanks for everyone's support!

I've updated the Wiki [1] and posted the two changes of phase 1 to Trac
[2, 3]. While I'm able to add the Functor/Applicative instances myself,
I'm not experienced enough with GHC to work on the "warnings" part though.

What remains to discuss is the addition of `join` due to the circular
dependency it introduces; [4] may be a future solution to this. Luckily,
we've still got time until phase 3, which is probably more than a year
ahead, to decide what to do. In the meantime I think we should suggest
removing custom `join` functions from module APIs just in case anyway.

Greetings,
David

[1]: http://www.haskell.org/haskellwiki/Functor-Applicative-Monad_Proposal
[2]: http://hackage.haskell.org/trac/ghc/ticket/8003
[3]: http://hackage.haskell.org/trac/ghc/ticket/8004
[4]: http://hackage.haskell.org/trac/ghc/ticket/7633

PS: Yipee :-)

Gmane