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

[Jan Stolarek]

> Previously the tagToEnum# was optimised away in the code generator in
> the common cases.  Perhaps the Simplifier will do that for the wrappers 
> now, I don't know. 
This special case is still in the code generator and it will be there until we move handling of 
tagToEnum# to Core. So using wrappers changes nothing - generated code is exactly the same as it 
used to be. Nothing gained, nothing lost.

> But if people are using primops, they are probably 
> deliberately writing low-level code and they don't want to be relying on
> optimisations that might not happen.
In which case they are free to modify their code to use the new primops. The only concern being 
that perhaps they might not be aware that what used to be a primop is now a normal function. But 
I'd assume that if someone decides to use primops then they are at least moderately following 
changes in the internals of GHC and will spot out that change in the release notes. That's my 
optimistic assumption.

> I don't mind breaking these very low-level APIs.
We are breaking that API at the moment, except that you propose to break it by chnaging type 
signatures, whereas I chose to break it by changing names. So currently the change in primops 
will not go unnoticed.

> We could always provide a GHC.Prim.Compat 
Well, that's what GHC.PrimWrappers is currently - it provides backwards compatibility (except for 
a few functions that Simon PJ pointed out, but I can easily change that).

Janek