Jason Dagit
On Sat, May 1, 2010 at 12:49 AM, Ivan Lazar Miljenovic < 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]))
But what is the point of that? That doesn't give you anything extra than specifying the type when you use it. Anyway, a better reason that I just thought of is that for some reason the type can only accept values of a certain type and thus mkGraph needs the constraint. However, I believe this goes against "the spirit" of the class (and would cause problem with nmap, emap, etc.). A better solution would be my still-so-far-mostly-vapourware generic graph class set where there is no requirement that the label types be mappable (which means I can't just scrap those classes when Louis and I start working on the new-and-improved FGL :s).
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
Hmmm... his code samples using the list monad seem to be non-existant for me, so I can't comment on them nor his rationales why this would be a good thing. Anyway, this split looks like the Applicative/etc. split that people have proposed. However, I still seem to recall someone telling me on #haskell that Monads, etc. are specifically _not_ meant to constrain the value type.
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.
-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com