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

[Simon Marlow]

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.

 > Wrappers are equivalent to previous
> implementation of primops: previously we had call to tagToEnum# generated implicitly by the code
> generator, whereas now we have an explicit call to tagToEnum# in the source code of the wrappers.

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. 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.

> I don't see a reason why we might want to break people's code, except for maybe making them aware
> that there was some change in primops implementation. I think that from the beginning new primops
> were meant to be used in branchless algorithms - most people don't need that.

The new primops are what we should have used in the first place :-) 
They map more closely to the machine operations, and thus expose more 
detail to the compiler for optimisation.  I've wanted to make this 
change for 15 years!

I don't mind breaking these very low-level APIs.  We could always 
provide a GHC.Prim.Compat for people who want to defer updating their 
code, we've done that kind of thing in the past (e.g. the 
Control.Exception migration).

Cheers,
	Simon