[Haskell-cafe] Pointed (was: Re: Restricted type classes)

[wren ng thornton]

On 9/6/10 11:50 AM, Gábor Lehel wrote:
> On Mon, Sep 6, 2010 at 5:11 PM, John Lato<jwlato at gmail.com>  wrote:
>> But please don't make Pointed depend on Functor - we've already
>> seen that it won't work for Bloom filters.
>
> I think most people have been using "Pointed" merely as shorthand for
> "Pointed Functor" -- in the same way that Applicative isn't called
> ApplicativeFunctor, even though that's what it is. So if it doesn't
> work for Bloom filters, the reason is that Bloom filters aren't
> pointed functors.

Exactly. For my part I don't particularly care whether the class 
defining unit requires fmap or not. Though, as I've mentioned earlier, I 
don't see any particular reason for omitting the dependency. In 
particular, one of the primary complaints against the Monad class is 
precisely the fact that it *fails* to mention the Functor class as a 
(transitive) dependency. Why should we believe that making unit 
independent from fmap will fare any better?

The unit natural transformation of pointed functors is not the same as 
any old inclusion function--- even if they are forced to agree when both 
are defined. Bloomfilters are not pointed functors. This is required, 
because bloomfilters are not structure preserving! But bloomfilters 
aren't terribly special in allowing a scalar type to be lifted into 
them. Vector spaces do the same thing; so do modules; so does path 
completion; so do free monoids; so does inclusion of real numbers into 
complex;... But one thing all of these examples has in common is that 
there is some particular structure which is preserved by the lifting 
process. The "associativity" between scalar multiplication and vector 
scaling, being one example. It's not clear to me that the singleton 
function for bloomfilters has any analogous structure it's preserving. 
Bloomfilters can be thought of as a sort of completion of the set of 
elements inserted into them, but there isn't much we can do to work with 
that.

One thing I am opposed to, however, is introducing a new class without 
being explicit about the laws and properties required of instances. If 
the class does not have a set of laws that it obeys, then it will only 
lead to confusion and poor design. Why bother giving a name to something 
that doesn't have a special and interesting structure? This failure of 
specification has led to problems in the MonadPlus class as well as the 
Alternative class, where people weren't sure what sort of structure 
those classes were supposed to be representing, and therefore came to 
conflicting conclusions.

In what sense can we define a unique parametric inclusion function that 
fails to meet the requirements of a pointed functor? What properties 
will this parametric inclusion function have, what laws will it require? 
Pointed functors do have laws; and explicitly mentioning these laws 
allows simplifying the definition of other classes (e.g., Applicative). 
But what laws do pointed non-functors have which make them a proper 
subclass of pointed functors? If we cannot come up with anything other 
than the parametricity of inclusion, then that would make me opposed to 
introducing this separate class. The only laws I can come up with for 
pointed types all make reference to some additional structure like the 
pointed type being a semiring, a functor, etc. I'm not sure that these 
additional structures all mean the same thing with the inclusion 
function they require, so I am uneasy with conflating them into a single 
class which satisfies no laws on its own.

-- 
Live well,
~wren