`OverlappingInstances` considered harmful considered harmful

#1

I see (third bullet here) OverlappingInstances is an example of something to be Deprecated. I won’t comment over there because @david-christiansen explicitly asks for feedback from ‘industrial Haskell users’ only.

I agree that with OverlappingInstances GHC could do a lot better; especially when you’re trying to combine with FunctionalDependencies. But we know what ‘better’ looks like – we know so well that it’s implemented. (In a Haskell that’s 15 years out of date, built on technology that’s 25 years out of date. Yes I am blaming and shaming GHC.)

That closed TypeFamilies offers very similar functionality is evidence it’s desired; that the work on DuplicateRecordFields and friends chose to use FunctionalDependencies shows TypeFamilies hasn’t taken over. (Indeed I hear mutterings that TypeFamilies will get obviated by DependentHaskell some day.)

Currently there seems no plan to do anything about the mess in GHC – it’s lost in the stampede for DependentHaskell. I suggest appearing to deprecate such a widely-used feature by fiat of a side-mention in a process-oriented proposal is not reflecting the intent here (see next message).

#2

I see the categorisation is based on comments in the User guide. And the User guide has "OverlappingInstances and IncoherentInstances … extensions are now deprecated (since GHC 7.10) …"

So if the aim of the proposal is to “provide a small number of expectations”, I suggest that particular expectation is better explained by including the continuing “… in favour of the fine-grained per-instance pragmas.” from the User guide. Or maybe including the pragmas as examples under Mature.

(Merely switching to per-instance pragmas doesn’t really fix the mess; it just localises it more visibly for somebody reading the code.)

1 Like
#3

Isn’t -XOverlappingInstances deprecated because it’s subsumed by per-instance pragmas re: overlappability? Not because the core idea is flawed.

9 Likes
#4

That’s right - the local pragmas allow it when intended, but help prevent unintentional confusing instance resolution in cases where it’s not intended.

7 Likes
#5

The proposal provides a small number of expectations simply as a reference point for how extensions might be classified. We very specifically did not classify everything as doing that is left as a separate task.

So just because this has an expectation that the language extension OverlappingInstances would be deprecated there is nothing binding to those expectations in the proposal. The GHC developers can decide to classify the extensions however they see fit.

The useful signal the proposal aims to get is exactly the GHC devs telling the rest of us what they consider the status of various extensions.

The per instance pragma versions of OverlappingInstances and IncoherentInstances are out of scope for the proposal. Which is about marking language extensions with a lifecycle, but the proposal is not making a statement on any other features GHC provides, like the per instance pragmas.

All of this does bring to my mind an interesting gap around how we might have better communication about the status of other features. Something to address the status of non-extensions based features (like per instance pragmas or other kinds of pragmas too!) could be a good future improvement. For now, let’s try to get one bit done and then build off that once we’ve got it.

I can relate to issues with typeclasses and instances being troublesome in different ways! Again, for this one proposal the scope is limited to only the language extension lifecycle.

3 Likes