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

Jan Stolarek jan.stolarek at
Thu Aug 22 15:43:29 CEST 2013

> 1. Why do you say "this naming feels more consistent"?  Consistent with what?
Convention is that functions ending with # operate on unboxed values and return unboxed values (usually), so to me it seemed consistent that sameTVar# returns an unboxed value, while sameTVar does not. I raised that problem on the Trac ( and the only answer I got was from Ian:

"Regarding the name of sameMutableArray#, I don't have a strong opinion. I suspect there are few users of the function, so personally I'd be inclined to use the most consistent names. "

So I assumed that everyone else agrees.

But anyway, this can be changed easily. We just need to agree on the names.

> 2.  The module name PrimWrappers is terrible, because it's so close to PrimopWrappers
Yes, I also don't like that similarity in names, but I don't think that current name is terrible - if I write sth like this:

  import GHC.Prim
  import GHC.PrimWrappers

it seems to be clearer whta the second module might contain, than if I write

  import GHC.Prim
  import GHC.BoolOpWrappers

Again, I can change this, but we have to decide on a name. CmpOpWrappers is not good IMO - not all wrappers are for comparisons!

> 3. Could you add a section "Breaking changes" to to explain what to change.  
Yes, I was thinking about that yesterday when I realized that second person asks the question which was already answered on the wiki. I wasn't sure where to put information about breaking changes so that it is easy to find for people who need it. I think that I'll make a spearate page on the wiki and link to it from release notes.


More information about the ghc-devs mailing list