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

Simon Marlow marlowsd at gmail.com
Sun Aug 25 20:28:18 CEST 2013


On 22/08/13 15:31, Simon Peyton-Jones wrote:
> | 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.

Oh gosh, I totally missed that all the primops were renamed in this 
change.  I would have suggested that we keep the names the same.  We 
really want people to use the new primops, not the wrappers, so it's the 
wrappers that should get the obscure names.

Is it too late to change this?

Cheers,
	Simon



> 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
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>





More information about the ghc-devs mailing list