On Sat, May 1, 2010 at 12:49 AM, Ivan Lazar Miljenovic <ivan.miljenovic@gmail.com> wrote:
Jason Dagit <dagit@codersbase.com> writes:

> On Sat, May 1, 2010 at 12:23 AM, Ivan Lazar Miljenovic <
> ivan.miljenovic@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