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

On 9/6/10 11:50 AM, Gábor Lehel wrote:

On Mon, Sep 6, 2010 at 5:11 PM, John Lato 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