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

On 7 September 2010 13:23, wren ng thornton wrote:

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?

Because there are some types for which pure/unit/singleton/etc. make sense but fmap doesn't?

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.

Ignoring that "Pointed" is used as a short-hand for "Pointed Functor": if we define a class with a method of type a -> c a, do we really need the Functor constraint? Is there anything stopping this class as well as Functor being super-classes of Applicative rather than Functor => Pointed => Applicative?

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.

If we have Foldable as well, we can define length/size. We can then define a law such that length (singleton x) == 1, which to me is the whole point of the singleton method/class. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com