Pointed [Re: 2014 Applicative => Monad proposal]

Dan Doel dan.doel at gmail.com
Sat May 25 17:33:31 CEST 2013

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

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

-- Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20130525/756c1d83/attachment-0001.htm>

More information about the Libraries mailing list