[project @ 2000-03-06 10:12:57 by sewardj]
authorsewardj <unknown>
Mon, 6 Mar 2000 10:12:57 +0000 (10:12 +0000)
committersewardj <unknown>
Mon, 6 Mar 2000 10:12:57 +0000 (10:12 +0000)
commit2add920879ae9107f8dffd6d2dbca174fb85fae3
treea53da825a9cb6250bc25474e4f1ee619a4822de3
parenta2f35a4647114bf93c2149925a6fa3bd87683452
[project @ 2000-03-06 10:12:57 by sewardj]
typeInstDefn(), the bit which invents GHC compatible instance names:
handle multiparam type classes.  This enables Hugs standalone to deal
multiparam type classes, but there's a fudge:

   class Foo s m where { }
   instance Foo s () where { }

GHC calls the instance $fFoos.  But Hugs records type vars as offsets,
and loses the name "s" in the instance head; all it knows about
are tyvar numbers (offsets), starting from zero.  So it can never
generate $fFoos here, only $fFoo0 (zero).  The resulting code works
in standalone mode but will not interwork with GHC.  In general tho,
multiparam type classes are not (yet) supported in combined mode;
interface.c certainly can't handle them.

It might be simplest in this case to change GHC's instance naming
defn to be the same as Hugs'.
ghc/interpreter/type.c