On 9/6/10 11:50 AM, Gábor Lehel wrote:
On Mon, Sep 6, 2010 at 5:11 PM, John Lato<jwl...@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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
