On 7 September 2010 13:23, wren ng thornton <w...@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<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?
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.miljeno...@gmail.com IvanMiljenovic.wordpress.com _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
