On Oct 9, 2013, at 3:41 PM, Joachim Breitner <m...@joachim-breitner.de> wrote:
> what do you need the extra bit for? During GHD, can’t you just create > the new dictionary (using "method = coerce original_method) and then see > if it typechecks, i.e. if the method types can be coerced. > Efficiency. You're absolutely right -- you could just run the check at a use site of GND. I just thought it was cleaner to talk about storing it. On Oct 9, 2013, at 3:41 PM, Edward Kmett <ekm...@gmail.com> wrote: > > This strikes me as a remarkably straightforward solution. Does it strike you > as something implementable in time for 7.8 though? > > Yes. I imagine updating the documentation will be harder than updating the implementation, especially if we go with Joachim's checking lazily idea -- that is, at the use site of GND instead of pre-calculating whether GND would work. The error messages would be easy to get right, and might actually be more informative than they currently are. Come to think of it, calculating this at the use site of GND is probably preferable as it will improve error messages -- users will see exactly which feature of a class makes it unsuitable for GND. This is a big improvement over the error message now. And, just a slightly-cleverer-than-the-dumbest-possible test here would allow, say, GND to work with (IArray UArray), a need which came up within GHC and with one of the failing packages on Hackage. > > Upon reflection it makes a lot of sense that GND has to mint a new > dictionary, because the superclasses may differ, like you showed here. Yes, of course. That's why it must be the way it is. On Oct 9, 2013, at 3:44 PM, Edward Kmett <ekm...@gmail.com> wrote: > The only class I'd want to preserve a representational roles for its > arguments for would be Coercible. > > It does strike me as interesting to consider what it would mean to properly > check other instances for overlap when the instances are defined only 'up to > representation'. > > It also strikes me as quite a rabbit hole. ;) Perhaps if IncoherentInstances is on, classes get representational roles. This actually makes sense -- IncoherentInstances says not to care about coherence, and the nominal roles on classes are to enforce coherence. The Coercible class is very incoherent (as in, *any* instance of the right type will work; we don't care which one), and so it should have representational roles, according to this logic. This default could be overridden by a type annotation, but I'm inclined *not* to let users override a class's default nominal role with an annotation. Richard _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
