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