Hello,
There are two type-classes in scalaz; Pointed and Copointed.

It is my opinion that the existence of these two traits is a bug.
Without getting too heavy into the theory, the primary consequence is a
failure of application of abstraction. If you use these in your code
explicitly, then I argue that you have a bug with this consequence.

I have long disliked Pointed/Copointed, since not too long after their
introduction, but recently, I have battled through implementing their
removal. The summary is that the point operation has now moved to
Applicative.

I am now keen to go ahead and fix all my dependent code. However, I bet
some of you do not feel as strongly as I do about this bug and so would
not be as keen.

Therefore, I put this subject out for discussion. If you only need
convincing that this is indeed an abstraction bug, then I will write the
essay. If you are just lazy and don't feel like updating your code
because you are on a cruise ship drinking pi�a coladas, then fine. I am
just putting it out there. Discuss!


--
Tony Morris
http://tmorris.net/

I strongly object to the removal of these two type-classes!  Pointed, in particular, is crucial for, e.g., the van Laarhoven representation of partial lens families, partial getters, and partial actions.  The diamond between Id, Option, NonEmptyList, and List is reflected in the parallel diamond between Functor, Pointed, Apply, and Applicative, respectively.  Removing Pointed is exactly like removig Option, except worse, because the type-class hierarchy is actually implemented subtype-wise.  Ideally, we'd have a Zero type-class like in Scalaz 6 as well, and for exactly the same reasons.
> because you are on a cruise ship drinking piña coladas, then fine. I am

> just putting it out there. Discuss!
>
>
> --
> Tony Morris
> http://tmorris.net/
>

> --
> You received this message because you are subscribed to the Google Groups "scalaz" group.
> To post to this group, send email to sca...@googlegroups.com.
> To unsubscribe from this group, send email to sca...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/scalaz?hl=en.
>

If I can demonstrate to you that you do not want Pointed, *especially*
for representing lens families, would you change your mind?

I have regretted the introduction of these two filthy type-classes since
forever. I am now paying the price!

On 28/12/12 11:13, Alexander Altman wrote:
> I strongly object to the removal of these two type-classes!  Pointed, in particular, is crucial for, e.g., the van Laarhoven representation of partial lens families, partial getters, and partial actions.  The diamond between Id, Option, NonEmptyList, and List is reflected in the parallel diamond between Functor, Pointed, Apply, and Applicative, respectively.  Removing Pointed is exactly like removig Option, except worse, because the type-class hierarchy is actually implemented subtype-wise.  Ideally, we'd have a Zero type-class like in Scalaz 6 as well, and for exactly the same reasons.
>
> On Dec 27, 2012, at 7:35 PM, Tony Morris <tonym...@gmail.com> wrote:
>
>> Hello,
>> There are two type-classes in scalaz; Pointed and Copointed.
>>
>> It is my opinion that the existence of these two traits is a bug.
>> Without getting too heavy into the theory, the primary consequence is a
>> failure of application of abstraction. If you use these in your code
>> explicitly, then I argue that you have a bug with this consequence.
>>
>> I have long disliked Pointed/Copointed, since not too long after their
>> introduction, but recently, I have battled through implementing their
>> removal. The summary is that the point operation has now moved to
>> Applicative.
>>
>> I am now keen to go ahead and fix all my dependent code. However, I bet
>> some of you do not feel as strongly as I do about this bug and so would
>> not be as keen.
>>
>> Therefore, I put this subject out for discussion. If you only need
>> convincing that this is indeed an abstraction bug, then I will write the
>> essay. If you are just lazy and don't feel like updating your code

>> because you are on a cruise ship drinking pi�a coladas, then fine. I am

If you can demonstrate to me that Pointed can be completely replaced in every possible use without breaking the proof properties of he code in question, then I would be okay with removing them, perhaps.

On Dec 27, 2012, at 8:21 PM, Tony Morris <tonym...@gmail.com> wrote:

> If I can demonstrate to you that you do not want Pointed, *especially*
> for representing lens families, would you change your mind?
>
> I have regretted the introduction of these two filthy type-classes since
> forever. I am now paying the price!
>
> On 28/12/12 11:13, Alexander Altman wrote:
>> I strongly object to the removal of these two type-classes!  Pointed, in particular, is crucial for, e.g., the van Laarhoven representation of partial lens families, partial getters, and partial actions.  The diamond between Id, Option, NonEmptyList, and List is reflected in the parallel diamond between Functor, Pointed, Apply, and Applicative, respectively.  Removing Pointed is exactly like removig Option, except worse, because the type-class hierarchy is actually implemented subtype-wise.  Ideally, we'd have a Zero type-class like in Scalaz 6 as well, and for exactly the same reasons.
>>
>> On Dec 27, 2012, at 7:35 PM, Tony Morris <tonym...@gmail.com> wrote:
>>
>>> Hello,
>>> There are two type-classes in scalaz; Pointed and Copointed.
>>>
>>> It is my opinion that the existence of these two traits is a bug.
>>> Without getting too heavy into the theory, the primary consequence is a
>>> failure of application of abstraction. If you use these in your code
>>> explicitly, then I argue that you have a bug with this consequence.
>>>
>>> I have long disliked Pointed/Copointed, since not too long after their
>>> introduction, but recently, I have battled through implementing their
>>> removal. The summary is that the point operation has now moved to
>>> Applicative.
>>>
>>> I am now keen to go ahead and fix all my dependent code. However, I bet
>>> some of you do not feel as strongly as I do about this bug and so would
>>> not be as keen.
>>>
>>> Therefore, I put this subject out for discussion. If you only need
>>> convincing that this is indeed an abstraction bug, then I will write the
>>> essay. If you are just lazy and don't feel like updating your code

>>> because you are on a cruise ship drinking piña coladas, then fine. I am

Let us be clear to start then. Pointed provides zero proof properties
and only serves to potentially invite broken code.

It is lawless on its own, except to the extent of a law provided by
parametricity. It therefore provides no value. Providing no value is one
thing, but inviting counter-productive code is another. It is a net
total loss of the less than zero.

If you accept that it provides zero value, or less than zero value, then
I have nothing to say except my own opinion that it provides
*significantly* less than zero value in practice with no redeeming
properties.

I am not clear on what your position might be on this.

As a side-note, here is a similar discussion that just occurred in IRC:

<dibblego> they are a failed abstraction
<dibblego> they should not exist
<dibblego> they provide no additional value
<dibblego> they are lawless, except for those laws that are proved by
parametricity anyway
<dibblego> their existence pretends to be valuable, which means a net
value of less than zero
<dibblego> this is a bug
<jedws> the concept is handy for describing different kinds of monads
<dibblego> woah there
<dibblego> there are two issues:
<dibblego> 1) they provide no value
<dibblego> 2) removing them is a breaking change
<dibblego> I am concerned only with 2)
<dibblego> 1) is well proven
<jedws> I don't automatically accept (1) � I trust that you know what
you are saying, but I can only believe it on trust
<dibblego> OK, well I guess I will have to write the essay
<dibblego> edwardk will certainly have something to say too
<dibblego> I thought it may have been discussed on haskell mailing lists
already, but looking now, I cannot find it
<jedws> k, I look forward to hearing it
<jedws> s/hearing/reading/
<dibblego> I can only find this:
<dibblego> http://www.haskell.org/haskellwiki/Typeclassopedia
<dibblego> (Note that previous versions of the Typeclassopedia explained
pure in terms of a type class Pointed, which can still be found in the
pointed package. However, the current consensus is that Pointed is not
very useful after all. For a more detailed explanation, see Why not
Pointed?)
<dibblego> http://www.haskell.org/haskellwiki/Why_not_Pointed%3F
<dibblego> The Pointed type class lives in the pointed library, moved
from the category-extras library.
<dibblego> Edward Kmett, the author of category-extras, pointed, and
many related packages, has since moved his focus to semigroupoids and
semigroups. He finds them more interesting and useful, and considers
Pointed to be historical now (he still provides the pointed package only
because �people were whinging�).
<edwardk> actually i don't use semigroupoids for much any more ;)
<dibblego> I don't think that's the reason anyway
<edwardk> its a useful layer though
<edwardk> jedws: the issue with pointed is that it provides you with no
real way to compose anything you get out of it, at all.
<dibblego> "semigroupoids exist" is not the strongest argument to be
made for: "pointed should not exist"
<edwardk> the only law you get is a free theorem
<edwardk> this means that a pointed functor might as well just be a
pointed type
<edwardk> but more damningly they invite you to use them in ways not
supported by their lack of laws
<edwardk> e.g. Set can be pointed. so you can make a singleton set a ->
Set a
<edwardk> ok, that seems fair, but when you have a bunch of them, what
can you do?
<edwardk> the fact that Set is a monoid and you can mappend them works
<edwardk> you can mappend the singleton sets
<edwardk> but this relies on completely ad hoc reasoning about this tyoe
<edwardk> if you have something else such that you have Pointed t and
Monoid (t a) you have to redo that reasoning
<edwardk> there is no law relating Pointed t and Monoid (t a) and no
meaningful way to stitch together its targets
<edwardk> virtually every use of pointed I've seen since I originally
foisted the idea off on the haskell community several years back has
been of this ad hoc nature.
<edwardk> I have come to regret that I ever pushed it
<dibblego> me too, since a few days after I did
<jedws> I'm afraid I'm still missing something�
<jedws> what do you mean by the ad-hoc reasoning of Set mappend?
<edwardk> i mean that the 'point' for your Set could very well just drop
the value 'a' on the floor
<jedws> right�
<edwardk> why is it singleton and not mempty?
<edwardk> that isn't in the laws anywhere
<edwardk> you have to _know_ about Set to reason about the correctness
of foldMap singleton
<edwardk> er foldMap point
<jedws> k, isn't that generally the case for Set (and Map) though?
* gianp has quit (Quit: This computer has gone to sleep)
<edwardk> my point is the parametricity on that signature isn't leading
you to any fundamental operation. you need to reason about every use of
'point' based on the concrete types it gets instantiated to. there are
lots of thoughts you can have about Apply or Applicative or Monad or
Bind that have nothing to do with the concrete instantiation
>>>> because you are on a cruise ship drinking pi�a coladas, then fine. I am

Alright.  What about abstracting over the ability to create singletons?  After reading the IRC log you provided, I'd be okay with making Pointed a synonym of [f[_]](Pure[f] with Functor[f]), but that would leave Pure as a type-class, and I don't see why we should get rid of that.
> <jedws> I don't automatically accept (1) – I trust that you know what

> you are saying, but I can only believe it on trust
> <dibblego> OK, well I guess I will have to write the essay
> <dibblego> edwardk will certainly have something to say too
> <dibblego> I thought it may have been discussed on haskell mailing lists
> already, but looking now, I cannot find it
> <jedws> k, I look forward to hearing it
> <jedws> s/hearing/reading/
> <dibblego> I can only find this:
> <dibblego> http://www.haskell.org/haskellwiki/Typeclassopedia
> <dibblego> (Note that previous versions of the Typeclassopedia explained
> pure in terms of a type class Pointed, which can still be found in the
> pointed package. However, the current consensus is that Pointed is not
> very useful after all. For a more detailed explanation, see Why not
> Pointed?)
> <dibblego> http://www.haskell.org/haskellwiki/Why_not_Pointed%3F
> <dibblego> The Pointed type class lives in the pointed library, moved
> from the category-extras library.
> <dibblego> Edward Kmett, the author of category-extras, pointed, and
> many related packages, has since moved his focus to semigroupoids and
> semigroups. He finds them more interesting and useful, and considers
> Pointed to be historical now (he still provides the pointed package only

> because “people were whinging”).
> <jedws> I'm afraid I'm still missing something…

> <jedws> what do you mean by the ad-hoc reasoning of Set mappend?
> <edwardk> i mean that the 'point' for your Set could very well just drop
> the value 'a' on the floor

> <jedws> right…
>>>>> because you are on a cruise ship drinking piña coladas, then fine. I am

On 28/12/12 11:40, Alexander Altman wrote:
> I'd be okay with making Pointed a synonym of [f[_]](Pure[f] with Functor[f])

What value would this provide? What are its laws?

It would, as I said, provide the ability to abstract over singleton structure creation.  As far as laws go, it would have exactly as many as Foldable.  :)

On 28/12/12 12:24, Alexander Altman wrote:
> the ability to abstract over singleton structure creation

I think this statement assumes some law. Or, what do you mean by singleton?

Foldable[F] says "F[A] is isomorphic to a free monoid generated by A". That implies a lot.