Splitting SYB from the base package in GHC 6.10

Jonathan Cast jonathanccast at fastmail.fm
Tue Sep 2 13:40:43 EDT 2008


> On Tue, Sep 2, 2008 at 11:59 AM, Bart Massey <bart at cs.pdx.edu> wrote:
> > Ian Lynagh <igloo <at> earth.li> writes:
> >> * You want to use a different instance for the same type.
> >>
> >>   Instances are global in Haskell, so if one library needs Ratio instance 1,
> >>   and another library needs Ratio instance 2, then those libraries cannot be
> >>   used in the same program.
> >
> > For me it's not so much about the libraries.  I've run into cases (not in SYB)
> > where I want my program to use a different definition of an instance than the
> > one provided by a library, while still using the other stuff provided by that
> > library.
> >
> > The pervasive globality of instances does seem to me to be a Haskell bug; it
> > seems to me like they ought to be controlled using the same module export
> > control rules as anything else.  But I imagine there's some reason I don't
> > understand that makes this hard or impossible...

I missed this the first time around, but consider the following case (I
ran into this specific issue trying to formulate arithmetic using
first-class modules and implicits):

class Multiplication alpha beta where
  type Product alpha beta
  (*) :: alpha -> beta -> Product alpha beta
class AdditiveGroup alpha where
  zero :: alpha
  (+) :: alpha -> alpha -> alpha
  (-) :: alpha -> alpha -> alpha
class (AdditiveGroup alpha,
       Multiplication alpha alpha, Product alpha alpha ~ alpha)
      => Field alpha where
  one :: alpha
  (/) :: alpha -> alpha -> alpha
class (AdditiveGroup vector, Field scalar,
       Multiplication scalar vector, Product scalar vector ~ vector)
      => VectorSpace scalar vector

And consider the definition

  multiply :: VectorSpace scalar scalar => scalar -> scalar -> scalar
  multiply = (*)

VectorSpace scalar scalar has two Multiplication scalar scalar
super-classes: one direct, and one inherited from Field.  With type
classes, this isn't a problem, because the program can only contain one
instance of Multiplication scalar scalar anyway (for fixed scalar), so
any instance must of VectorSpace scalar scalar necessarily picks up only
one definition of (*).  If you had named instances, and relaxed that
uniqueness constraint, I'm not even sure how you'd express that when you
needed it here.

jcc




More information about the Libraries mailing list