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

[Simon Peyton-Jones]

| Oh, and I think that using sameTVar# for primop and sameTVar for wrapper
| is a good choice, even if we make transition slightly more difficult.
| This naming feels better to me 

You said that before, but *why* does the "naming feel better" to you?

We now have 
	ltFloatI# :: Float# -> Float# -> Int#   (the primop)
	ltFloat#  :: Float# -> Float# -> Bool   (wrapper)
	ltFloat   :: Float  -> Float  -> Bool   (in GHC.Float)

So it makes sense to me to have
	sameTVarI# :: TVar# s a -> TVar# s a -> Int# (the primop)
	sameTVar#  :: TVar# s a -> TVar# s a -> Bool (wrapper)
	sameTVar   :: TVar s a  -> TVar s a  -> Bool (in GHC.Conc.Sync)

(Actually GHC.Conc.Sync doesn't define sameTVar; it just gives an Eq instance, but you see the idea.)

I don’t see why you propose to break the consistency of this naming convention.

Simon
		
	
| 
| Janek
| 
| ----- Oryginalna wiadomość -----
| Od: "Jan Stolarek" <jan.stolarek at p.lodz.pl>
| Do: "Simon Peyton-Jones" <simonpj at microsoft.com>
| DW: ghc-devs at haskell.org, "Gabor Greif" <ggreif at gmail.com>
| Wysłane: czwartek, 22 sierpień 2013 14:43:29
| Temat: Re: Changes to primops break libraries (was Re: 7.8 Feature
| window)
| 
| > 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
| (http://ghc.haskell.org/trac/ghc/ticket/6135#comment:72) 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
| http://ghc.haskell.org/trac/ghc/wiki/PrimBool 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.
| 
| Janek