"Carl R. Witty" wrote:
> "Jeffrey R. Lewis" <[EMAIL PROTECTED]> writes:
>
> > Marcin 'Qrczak' Kowalczyk wrote:
> > > Parts of context reduction must be deferred, contexts must be left
> > > more complex, which as I understand leads to worse code - only to
> > > make overlapping instances behave consistently, even where they are
> > > not actually used.
> ...
> > When you say: `even where they are not actually used', I'm not sure what you
> > mean. The deferred reduction only happens on classes with overlap. Classes
> > without overlap will be `eagerly' reduced.
>
> How can that work? Given separate compilation, you don't know whether
> a class has overlapping instances or not, do you?
As with context reduction in general, it is always done with respect to what
instances are in scope. Let's make it concrete:
module T where
class Ick a where ick :: a
instance Ick Int where ick = 17
instance Ick a => Ick [a] where ick = [ick]
module S where
import T
instance Ick [Int] where ick = [13]
If you've only got module T loaded, then ick :: [Int] has value [17]. If you've
got module S loaded, then ick :: [Int] has value [13].
This is why overlapping instances aren't in standard Haskell ;-) But if you turn
on +o in hugs or -fallow-overlapping-instances in GHC, then you're saying that you
understand this (he asserts boldly...). But this is manageable by making sure you
load your modules in the right order (and the compiler *could* issue a warning if
you didn't - if it was deemed worthy of the additional bookkeeping). The problem
that I was describing as being recently fixed, caused overlapping instances to
behave inconsistently even within the same scope of instances.
--Jeff
