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

[Ivan Lazar Miljenovic]

On 7 September 2010 13:23, wren ng thornton <wren at freegeek.org> wrote:
> 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?

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 at gmail.com
IvanMiljenovic.wordpress.com