Changes to primops break libraries (was Re: 7.8 Feature window)
jan.stolarek at p.lodz.pl
Thu Aug 22 17:12:33 CEST 2013
You're right Simon - I didn't thought about ltFloat and that my idea of "consistency" breaks there.
----- Oryginalna wiadomość -----
Od: "Simon Peyton-Jones" <simonpj at microsoft.com>
Do: "Jan Stolarek" <jan.stolarek at p.lodz.pl>
DW: ghc-devs at haskell.org, "Gabor Greif" <ggreif at gmail.com>
Wysłane: czwartek, 22 sierpień 2013 15:31:32
Temat: RE: Changes to primops break libraries (was Re: 7.8 Feature window)
| 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.
| ----- 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
| > 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
| > 2. The module name PrimWrappers is terrible, because it's so close to
| 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
| 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.
More information about the ghc-devs