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 and I think there are few libraries that will need to adjust. So I vote to keep these names as they are.
Janek ----- Oryginalna wiadomość ----- Od: "Jan Stolarek" <jan.stola...@p.lodz.pl> Do: "Simon Peyton-Jones" <simo...@microsoft.com> DW: ghc-devs@haskell.org, "Gabor Greif" <ggr...@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@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
