<Moving from libraries to haskell-cafe...>
I wrote:
>> ...there must be some
>> way to control the import and export of instances, just as we can
>> now control the import and export of every other kind of symbol
>> binding.
Henning Thielemann wrote:
> For me it's most often the case that an instance is missing.
> If there is no way to change existing instance definitions,
> then you must use 'newtype'.
Yes, in that case newtype is a work-around, often messy.
> Generalized newtype deriving simplifies to adapt the instances you want.
That's only one part of it. Using a newtype can sometimes spew
wreckage all over the place.
But a more difficult case is when you need to use two libraries
that already define conflicting instances. That requires
a newtype plus however many adaptor functions you need,
all inside a wrapper module. What a mess.
These cases are likely to arise most often in large software projects.
So there hasn't been a big enough demand yet for this feature to be
implemented in any compiler, resulting in it being rejected from
Haskell', unfortunately.
But for large projects it has to work the other way around - the
language features need to be there already for the language
to be adopted for the project. Or to keep project managers
from cursing themselves later on if they do choose Haskell.
Anyway, I find the current behavior to be ugly and unintuitive.
Why is it that when I say
import Control.Monad.Error (throwError, runErrorT)
there is no way to prevent also getting a surprising Monad Either
instance? Never mind how things should have been named
in Control.Monad.Error - that's the way it is right now. I need to
be able to import the module without getting the instance.
Regards,
Yitz
