Re: Changes to primops break libraries (was Re: 7.8 Feature window)

On 26/08/13 09:56, Gregory Collins wrote:

On Sun, Aug 25, 2013 at 9:47 PM, Simon Marlow mailto:marlowsd@gmail.com> wrote:

On 25/08/13 20:16, Jan Stolarek wrote:

We really want people to use the new primops, not the wrappers

We do? Could you justify why we want to people to use primops?

What I meant was, if people are already using primops we want them to use the new ones instead.

Please don't just break existing code!

I understand the need to not break code. But in this case, code is already breaking. I only suggested that since we're already breaking code, we shouldn't have to put up with ugly primop names too. If we really want to not break code at all, and hence keep the base major version the same, even in a major release, that's a whole separate discussion that leads on to the base-split discussion on the libraries list right now. We can (and have) supplied two base versions with GHC in the past but it's a real pain. Reorganising the packages would make it easier in the future.

Changing the meaning of existing names, even if those are the names you really really want to use, is user-hostile: when the next version of GHC comes out I'm going to have to rush to update my broken packages under time pressure instead of just getting a deprecation warning and improving the code at my leisure. If you reeeeallly really really want those names then there are ways to mitigate that: do your "GHC.Prim.Compat" trick in reverse.

We could have a smooth transition by renaming GHC.Prim to GHC.ReallyPrim or something. But then what do we do next time? GHC.ReallyReallyPrim? This doesn't seem like a sustainable policy, and it's at odds with the way we normally manage API transitions. Cheers, Simon