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.

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

On 23/05/13 22:20, Shachaf Ben-Kiki wrote:

On Thu, May 23, 2013 at 4:17 PM, Herbert Valerio Riedel 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

-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@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@haskell.org http://www.haskell.org/**mailman/listinfo/librarieshttp://www.haskell.org/mailman/listinfo/libraries

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 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_Pointedhttp://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@haskell.org http://www.haskell.org/**mailman/listinfo/librarieshttp://www.haskell.org/mailman/listinfo/libraries

On Thu, May 23, 2013 at 5:02 PM, Ivan Lazar Miljenovic wrote:

On 24 May 2013 05:39, David Luposchainsky 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/e137645db268... Basically, someone is refactoring the Idris typeclasses to add Applicative as a superclass of Monad and observed the same thing. Jason

+1 for AMP (with or without DefaultSignatures) +1 for MINIMAL pragma On Fri, May 24, 2013 at 8:26 AM, Dan Burton 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@haskell.org http://www.haskell.org/mailman/listinfo/libraries

+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 mailto:danburton.email@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@haskell.org mailto:Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@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@ifi.lmu.de http://www2.tcs.ifi.lmu.de/~abel/

I completely agree with Edward here. * Edward Kmett [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 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 >> 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@haskell.org mailto:Libraries@haskell.org http://www.haskell.org/**mailman/listinfo/librarieshttp://www.haskell.org/mailman/listinfo/libraries

______________________________**_________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/**mailman/listinfo/librarieshttp://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@ifi.lmu.de http://www2.tcs.ifi.lmu.de/~**abel/ http://www2.tcs.ifi.lmu.de/~abel/

______________________________**_________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/**mailman/listinfo/librarieshttp://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

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 [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 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@ifi.lmu.de http://www2.tcs.ifi.lmu.de/~abel/

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 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 [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 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@ifi.lmu.de http://www2.tcs.ifi.lmu.de/~abel/

...

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

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 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 [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 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@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@ifi.lmu.de http://www2.tcs.ifi.lmu.de/~abel/

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 mailto:andreas.abel@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 mailto:ekmett@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 mailto:andreas.abel@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@ifi.lmu.de mailto:andreas.abel@ifi.lmu.de http://www2.tcs.ifi.lmu.de/~__abel/ http://www2.tcs.ifi.lmu.de/~abel/

_________________________________________________ Libraries mailing list Libraries@haskell.org mailto:Libraries@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@ifi.lmu.de http://www2.tcs.ifi.lmu.de/~abel/

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 mailto:andreas.abel@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@ifi.lmu.de http://www2.tcs.ifi.lmu.de/~abel/

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 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 >> 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@ifi.lmu.de http://www2.tcs.ifi.lmu.de/~**abel/ http://www2.tcs.ifi.lmu.de/~abel/

______________________________**_________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/**mailman/listinfo/librarieshttp://www.haskell.org/mailman/listinfo/libraries

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

On Fri, May 24, 2013 at 2:15 PM, Andreas Abel mailto:andreas.abel@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|.

+1, if it isn't too late to vote

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

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