[Haskell-cafe] FGL instance constraint

[Jason Dagit]

On Sat, May 1, 2010 at 12:49 AM, Ivan Lazar Miljenovic <
ivan.miljenovic at gmail.com> wrote:

> Jason Dagit <dagit at codersbase.com> writes:
>
> > On Sat, May 1, 2010 at 12:23 AM, Ivan Lazar Miljenovic <
> > ivan.miljenovic at gmail.com> wrote:
> >
> >> Hmmm.... this is an interesting way of doing it, but I would argue that
> >> it's pointless: the fact that you're using MPTCs doesn't give you
> >> anything extra that the original class.  Furthermore, as I said earlier,
> >> it doesn't make sense to constrain the label type just to make an
> >> instance of a type class.
> >>
> >> (Now, if we had other functions in there which _might_ depend on the
> >> label types, this _would_ make sense; as it stands however, it doesn't.)
> >>
> >
> > Try removing "Cls a" from the instance.  You'll notice that my empty does
> > depend on a having a Cls instance because it will fail to compile.  In
> other
> > words, I don't understand what you're talking about.  I did need the
> > constraint to define my instance.
>
> Except that example is bogus: "isEmpty empty" returns False.
>

I thought we were discussing how expressive the Graph typeclass is, not
whether I made a sensible implementation.  I mean, I could pretty easily fix
that "problem", but I think that's not the important topic.  For example,
change empty to this:
  empty = GrB (B ([] `asTypeOf` [boring]))

Without seeing all of Kevin's instance, it's really hard to say whether or
not it actually matters for him.  I'm not understanding how you can
automatically infer it doesn't matter here.


> > And if that example gets boring, try making an instance of Set for
> > Monad.
>
> My understanding was that Set couldn't be a Monad specifically why you
> can't make it one: Monads shouldn't constrain the value of the type
> contained within.
>

I'm not a category theorist, but others seem to have looked into that issue
in depth:
http://www.randomhacks.net/articles/2007/03/15/data-set-monad-haskell-macros

At the bottom, you'll see some extra monad laws that need to be satisfied
due to the constraint.  In particular:
fmap f . return == return . f
fmap f . join == join . fmap (fmap f)


> >  Then re-read the article I linked from Oleg's website.  I'm not
> > understanding your point, and I suspect you're not understanding mine
> > :)
>
> My point was that Kevin was doing it wrong and didn't need a constraint
> there; what's yours?
>

I completely agreed that having the constraint in the data declaration was a
bad idea.  Then I took it a step further to assume it may still come up in
the definition of the Graph instance for Kevin or others.  So then I made up
a silly example where it does matter.  Hopefully Kevin will post back
letting us know what worked (or didn't) for him.

Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20100501/4ff9556c/attachment.html