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

Simon Marlow marlowsd at
Mon Aug 26 12:05:34 CEST 2013

On 26/08/13 09:56, Gregory Collins wrote:
> On Sun, Aug 25, 2013 at 9:47 PM, Simon Marlow <marlowsd at
> <mailto:marlowsd at>> 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.


More information about the ghc-devs mailing list