Superclass defaults

[Jonas Almström Duregård]

> The question then comes down to whether that warning should ever be
> strengthened to an error.

Indeed.

> I agree that such a scenario is possible. The present situation gives
> no choice but to do things badly, but things often get done badly the
> first time around anyway. Perhaps I'm just grumpy, but I think we
> should aim to make bad practice erroneous where practicable. Once
> the mistake is no longer forced upon us, it becomes a mistake that
> deserves its penalty in labour. Silent pre-emption is bad practice and
> code which relies on it should be fixed: it's not good to misconstrue
> an instance declaration because you don't know which instance
> declarations are somewhere else. Nonmonotonic reasoning is always a
> bit scary.
>
> From a library design perspective, we should certainly try to get these
> hierarchical choices right when we add classes. I accept that it should
> be cheap to fix mistakes (especially when the mistake is lack of
> foresight. Sticking with the warning rather than the error reduces the
> price of this particular legacy fix at the cost of tolerating misleading
> code. I agree that the balance of this trade-off is with the warning,
> for the moment, but I expect it to shift over time towards the error.
> But if it's clear what the issue is, then we can at least keep it under
> review.

I agree. Making bad practice erroneous is good, but its not really the
bad practice that raises the error here. You have no serious problems
until you try to change your bad design to a good one. Like you say it
should be cheap to fix mistakes.

>> Will there be a solution to this dilemma that I have missed? Should
>> the client code be allowed opt-out from the superclass preemptively
>> before it is given a default? Won't that cause a similar perplexity?
>
> I don't know what you mean by this. Perhaps you could expand on it?

What I'm trying to ask is if you can write compatible code that will
work across gradual changes of the compiler and the libraries.

Suppose we have library with class C. In a newer version of the
library we add an intrinsic superclass S. Also suppose the compiler
implements option 1. Now the users of the library want to write code
that uses both C and S, and that's compatible with both the new and
the old library. From what I can tell there are three situations that
needs to be covered:

1) Old compiler - Old library
Here we need to specify both instances, and we cant hide the default S
instance because its not supported by the compiler. This also applies
for other situations where the client must use Haskell 2010 compatible
code.

2) New compiler - Old library
Here we also need to specify both instances.

3) New compiler - New library
We can either write both instances and hide the default or we can just
write an instance for C.

Clearly code that covers situation 1 will never be compatible with situation 3.

The question I was asking was if we are allowed to hide the default
instance of S in situation 2. In that case you can write compatible
code for situation 2 and 3. The possible confusion from this is that
you hide a default implementation thats not defined. Maybe it's not as
bad as overriding silently, but there is some room for error where you
think you have blocked a superclass instance but really you have just
blocked some completely unrelated class.

Of course we can get compatibility across all three using CPP but I
really wish we won't need that.

As time passes, situation 1 will become more rare, although situation
2 and 3 can reoccur endlessly as new libraries are designed and
redesigned.

Regards,
Jonas