Changing scope?

[sol]

I'm puzzled whether we should change scope of base-compat. Obviously, orphans are the most controversial, this is why I suggested to move them to base-orpahns here ekmett/semigroupoids#27.

Adding data types and classes has less sever composability issues, but may still be somewhat controversial.

On the other hand I don't see any issues with adding new functions and simple export reordering (what we do for Prelude.Compat and Data.List.Compat for the AMP/Foldable/Traversable changes). At the same time this kind of changes give me the biggest benefit. This is why I'm puzzled whether we should change scope to only do this kind of changes. That would mean:

• We only add functions and do export reordering
• We do not define any data types
• We do not add classes
• We do not add orphans, but they can go into base-orphans instead

We could broaden the scope in the future if it turns out that both of the following holds:

1. the community agrees on base-compat as the single library for dealing with breaking changes in base
2. there is community consensus to do so

[sol]

@RyanGlScott @ekmett Any input on this one?

[RyanGlScott]

I'm definitely on board with the base-orphans idea, especially since it would allow us to ensure that each base-compat module exports the orphan instances it needs to be in scope, which is becoming more and more of an issue as base-compat grows.

I agree that we should be cautious about redefining already existing ADTs/typeclasses, but I don't think we need to ban them outright. For instance, some ADTs, like Down and Alt, have predictable behavior and are unlikely to have their definitions change—I think it would be acceptable to backport these.

I would propose these guidelines for determining if an ADT or typeclass deserves to be backported:

• Don't backport typeclasses used for GHC-specific syntactic sugar (MonadFix, MonadZip, etc.)
• Don't backport typeclasses that would be difficult to implement by hand (Generic, Generic1, etc.)
• Don't backport ADTs/typeclasses whose values are unlikely to be created by a programmer him/herself (the data types from GHC.Generics, etc.). In other words, make sure they'd actually be useful to someone (FiniteBits seems to be one such example).
• Don't backport typeclasses whose functions have completely changed between versions of base (PrintfArg from Text.Printf comes to mind).

[sol]

I would also not backport data types that are still provided by an other package (e.g. Data.Proxy), unless the author of that package is ok with depending / re-exporting from base-compat.

I still lean towards focusing on functions only for now. It is a simple policy that is easy to communicate and understand, it has little potential for controversies, and it already provides most of the benefits (at least for my use cases).

Community acceptance is currently my main concern (that includes me, as currently I would not be fine with depending on base-compat myself for a widely used library, so far I use it for smaller projects, in-house stuff and executables / tests).

@RyanGlScott Still, if you think it's crucial to redefine a specific data type or class, I'm ok with that if that data type or class is not defined anywhere else on Hackage + I would rely on you to do the research.

[RyanGlScott]

I certainly want base-compat to be used as much as possible, so in pursuit of that goal, I'm willing to exclude data types and typeclasses. (I wouldn't call Alt/Down/FiniteBits "cruicial", just low-hanging fruit in the quest for maximum backwards compatibility :) ).

[RyanGlScott]

And with base-compat-0.8.0, these changes have been implemented.