The base library and GHC 6.10

[Claus Reinke]

>I'm all for addressing the real issues!  But there are two time-frames involved
>a) In the next fortnight we must decide what stays in 'base' and what moves to the new 'syb' 
>package.
>b) On a longer timescale, the 'syb' package maintainers can improve the library.
>The whole point of splitting syb out is to decouple (b) from (a).
>I'm currently focused on (a), because it is urgent, and this is the discussion that Jose is
>now kindly chairing.  (b) remains important, but it is less urgent.

understood and agreed. We just need to make sure that decoupling
'Data' from the decoupling of 'syb' doesn't ruin the intended decoupling!-)

| - ghc sessions retaining instances (#2182), leading to build errors
|     even in separate module hierarchies

>Yes I agree this is bad, but I don't think I can fix it in time for 6.10;
>it's a consequence of an ill-made but fairly deeply wired in design choice.

Just knowing whether you actually hope to do something about it,
or whether it is so deeply ingrained that it can't be fixed, would help.

| - ghc listing "orphan instances" as a performance issue,
|     re-emphasized recently by warnings turned into errors, which
|     has led some to believe they are a design fault, rather than a
|     representation of a valid design decision

>They are not turned into errors.  They are simply warnings.  They
>only appear if you ask for them.  If you use -Werror then they turn
>into errors, but then you asked for that!  (The recent change is that
>previously they were second-class warnings that did not have this property.)

You have made your views quite clear in previous messages.
Unfortunately, that doesn't keep others from drawing other
conclusions, turning against any instance of orphans;-)

Claus