Re: Changes to primops break libraries (was Re: 7.8 Feature window)
On Mon, Aug 26, 2013 at 12:51 PM, Herbert Valerio Riedel wrote: > ...btw, do we actually know which (or how many) packages are affected? I believe at least one of my packages will be affected, and even if we go and run the analysis on Hackage (I expect only a handful of packages to run into this API change), there's the "dark matter" not visible to us in all of the commercial Haskell codebases to consider. Naming is important, but IMO not so important that you need to break working user programs to hang onto a preferred name, at least not without a deprecation cycle of at least one major GHC version. G -- Gregory Collins ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Changes to primops break libraries (was Re: 7.8 Feature window)
I guess that's a valid argument. I'll discuss this with Simon tomorrow. Janek Dnia poniedziałek, 26 sierpnia 2013, Simon Marlow napisał: > On 26/08/13 10:38, Jan Stolarek wrote: > >> So since we have to break the API anyway, why not break it in the way > >> that we want? > > > > Oh, but the thing is we don't! We have a plan to rename GHC.Prim to > > GHC.Prim.BuiltIn, rename GHC.PrimWrappers (in ghc-prim) to GHC.Prim and > > make it re-export GHC.Prim.BuiltIn [1]. This way change will be > > completely backwards compatible. I was working on that on Friday. Patches > > are essentially finished, but I still have to solve haddock panic that I > > somehow introduced [2]. > > I'm sorry, but I just don't like this solution. We could do this every > time we change an API, but imagine what a mess we'd be in by now! It's > just not the right way to manage API changes. > > Cheers, > Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Changes to primops break libraries (was Re: 7.8 Feature window)
On 2013-08-26 at 10:56:15 +0200, Gregory Collins wrote: > On Sun, Aug 25, 2013 at 9:47 PM, Simon Marlow wrote: >> On 25/08/13 20:16, Jan Stolarek wrote: >>> We really want people to use the new primops, not the wrappers >>> We do? Could you justify why we want to people to use primops? >>> >> >> What I meant was, if people are already using primops we want them to use >> the new ones instead. > > Please don't just break existing code! ...btw, do we actually know which (or how many) packages are affected? ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Changes to primops break libraries (was Re: 7.8 Feature window)
On 26/08/13 10:38, Jan Stolarek wrote: So since we have to break the API anyway, why not break it in the way that we want? Oh, but the thing is we don't! We have a plan to rename GHC.Prim to GHC.Prim.BuiltIn, rename GHC.PrimWrappers (in ghc-prim) to GHC.Prim and make it re-export GHC.Prim.BuiltIn [1]. This way change will be completely backwards compatible. I was working on that on Friday. Patches are essentially finished, but I still have to solve haddock panic that I somehow introduced [2]. I'm sorry, but I just don't like this solution. We could do this every time we change an API, but imagine what a mess we'd be in by now! It's just not the right way to manage API changes. Cheers, Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Changes to primops break libraries (was Re: 7.8 Feature window)
On 26/08/13 09:56, Gregory Collins wrote: On Sun, Aug 25, 2013 at 9:47 PM, Simon Marlow mailto:marlo...@gmail.com>> wrote: On 25/08/13 20:16, Jan Stolarek wrote: We really want people to use the new primops, not the wrappers We do? Could you justify why we want to people to use primops? What I meant was, if people are already using primops we want them to use the new ones instead. Please don't just break existing code! I understand the need to not break code. But in this case, code is already breaking. I only suggested that since we're already breaking code, we shouldn't have to put up with ugly primop names too. If we really want to not break code at all, and hence keep the base major version the same, even in a major release, that's a whole separate discussion that leads on to the base-split discussion on the libraries list right now. We can (and have) supplied two base versions with GHC in the past but it's a real pain. Reorganising the packages would make it easier in the future. Changing the meaning of existing names, even if those are the names you really really want to use, is user-hostile: when the next version of GHC comes out I'm going to have to rush to update my broken packages under time pressure instead of just getting a deprecation warning and improving the code at my leisure. If you rallly really really want those names then there are ways to mitigate that: do your "GHC.Prim.Compat" trick in reverse. We could have a smooth transition by renaming GHC.Prim to GHC.ReallyPrim or something. But then what do we do next time? GHC.ReallyReallyPrim? This doesn't seem like a sustainable policy, and it's at odds with the way we normally manage API transitions. Cheers, Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Changes to primops break libraries (was Re: 7.8 Feature window)
> So since we have to break the API anyway, why not break it in the way > that we want? Oh, but the thing is we don't! We have a plan to rename GHC.Prim to GHC.Prim.BuiltIn, rename GHC.PrimWrappers (in ghc-prim) to GHC.Prim and make it re-export GHC.Prim.BuiltIn [1]. This way change will be completely backwards compatible. I was working on that on Friday. Patches are essentially finished, but I still have to solve haddock panic that I somehow introduced [2]. [1] - http://www.haskell.org/pipermail/ghc-devs/2013-August/002072.html [2] - http://www.haskell.org/pipermail/ghc-devs/2013-August/002124.html ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Changes to primops break libraries (was Re: 7.8 Feature window)
On 26/08/13 09:50, Jan Stolarek wrote: I don't mind breaking these very low-level APIs. We are breaking that API at the moment, except that you propose to break it by chnaging type signatures, whereas I chose to break it by changing names. So currently the change in primops will not go unnoticed. So since we have to break the API anyway, why not break it in the way that we want? Cheers, Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Changes to primops break libraries (was Re: 7.8 Feature window)
On Sun, Aug 25, 2013 at 9:47 PM, Simon Marlow wrote: > On 25/08/13 20:16, Jan Stolarek wrote: > >> We really want people to use the new primops, not the wrappers >>> >> We do? Could you justify why we want to people to use primops? >> > > What I meant was, if people are already using primops we want them to use > the new ones instead. Please don't just break existing code! Changing the meaning of existing names, even if those are the names you really really want to use, is user-hostile: when the next version of GHC comes out I'm going to have to rush to update my broken packages under time pressure instead of just getting a deprecation warning and improving the code at my leisure. If you rallly really really want those names then there are ways to mitigate that: do your "GHC.Prim.Compat" trick in reverse. In any event, a 0-month deprecation cycle is far too short, even for low-level APIs. G -- Gregory Collins ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Changes to primops break libraries (was Re: 7.8 Feature window)
> Previously the tagToEnum# was optimised away in the code generator in > the common cases. Perhaps the Simplifier will do that for the wrappers > now, I don't know. This special case is still in the code generator and it will be there until we move handling of tagToEnum# to Core. So using wrappers changes nothing - generated code is exactly the same as it used to be. Nothing gained, nothing lost. > But if people are using primops, they are probably > deliberately writing low-level code and they don't want to be relying on > optimisations that might not happen. In which case they are free to modify their code to use the new primops. The only concern being that perhaps they might not be aware that what used to be a primop is now a normal function. But I'd assume that if someone decides to use primops then they are at least moderately following changes in the internals of GHC and will spot out that change in the release notes. That's my optimistic assumption. > I don't mind breaking these very low-level APIs. We are breaking that API at the moment, except that you propose to break it by chnaging type signatures, whereas I chose to break it by changing names. So currently the change in primops will not go unnoticed. > We could always provide a GHC.Prim.Compat Well, that's what GHC.PrimWrappers is currently - it provides backwards compatibility (except for a few functions that Simon PJ pointed out, but I can easily change that). Janek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Changes to primops break libraries (was Re: 7.8 Feature window)
On 25/08/13 20:16, Jan Stolarek wrote: We really want people to use the new primops, not the wrappers We do? Could you justify why we want to people to use primops? What I meant was, if people are already using primops we want them to use the new ones instead. > Wrappers are equivalent to previous implementation of primops: previously we had call to tagToEnum# generated implicitly by the code generator, whereas now we have an explicit call to tagToEnum# in the source code of the wrappers. Previously the tagToEnum# was optimised away in the code generator in the common cases. Perhaps the Simplifier will do that for the wrappers now, I don't know. But if people are using primops, they are probably deliberately writing low-level code and they don't want to be relying on optimisations that might not happen. I don't see a reason why we might want to break people's code, except for maybe making them aware that there was some change in primops implementation. I think that from the beginning new primops were meant to be used in branchless algorithms - most people don't need that. The new primops are what we should have used in the first place :-) They map more closely to the machine operations, and thus expose more detail to the compiler for optimisation. I've wanted to make this change for 15 years! I don't mind breaking these very low-level APIs. We could always provide a GHC.Prim.Compat for people who want to defer updating their code, we've done that kind of thing in the past (e.g. the Control.Exception migration). Cheers, Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Changes to primops break libraries (was Re: 7.8 Feature window)
> We really want people to use the new primops, not the wrappers We do? Could you justify why we want to people to use primops? Wrappers are equivalent to previous implementation of primops: previously we had call to tagToEnum# generated implicitly by the code generator, whereas now we have an explicit call to tagToEnum# in the source code of the wrappers. I don't see a reason why we might want to break people's code, except for maybe making them aware that there was some change in primops implementation. I think that from the beginning new primops were meant to be used in branchless algorithms - most people don't need that. Also, Simon PJ has come up with an idea for some optimisations that would deal with tagToEnum# at the Core level, but I will almost certainly not have time to implement them during my internship. > Is it too late to change this? I think that before 7.8 is released we can change anything we want in these primops. We just need to decide what we want - I've spent last Friday on making primops change completely backwards compatible. Janek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Changes to primops break libraries (was Re: 7.8 Feature window)
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" | Do: "Simon Peyton-Jones" | DW: ghc-devs@haskell.org, "Gabor Greif" | 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 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Changes to primops break libraries (was Re: 7.8 Feature window)
Sure. I considered that idea at some point but it seemed a bit to drastic. Janek - Oryginalna wiadomość - Od: "Simon Peyton-Jones" Do: "Geoffrey Mainland" , "Jan Stolarek" DW: ghc-devs@haskell.org Wysłane: czwartek, 22 sierpień 2013 17:57:48 Temat: RE: Changes to primops break libraries (was Re: 7.8 Feature window) I think that's a pretty good idea. It's not just a hack... it makes sense even if you ignore the issues of managing the transition. Maybe GHC.Prim.Builtin for the machine-generated not-written-in-Haskell operations. Jan would you like to try it? Simon | -Original Message- | From: Geoffrey Mainland [mailto:mainl...@apeiron.net] | Sent: 22 August 2013 16:18 | To: Jan Stolarek | Cc: Simon Peyton-Jones; ghc-devs@haskell.org | Subject: Re: Changes to primops break libraries (was Re: 7.8 Feature | window) | | This is not a completely serious suggestions, but... If we moved the | magic GHC.Prim module to GHC.Prim.Base or something, then we could move | GHC.PrimWrappers to GHC.Prim, have it import GHC.Prim.Base, and, | assuming that we use Simon PJ's naming convention, (I think) no code | would have to change. | | Geoff | | On 08/22/2013 03:49 PM, Jan Stolarek wrote: | > I created a wiki page that describes the upgrade process in two easy | steps: | > | > http://ghc.haskell.org/trac/ghc/wiki/NewPrimopsInGHC7.8 | > | > I also added link to this page in the release notes. Simon, does this | address points 3 & 4 of your mail? Of course aside from the fact that if | we change name of GHC.PrimWrappers module than these page will need to | be updated accordingly. | > | > Janek | > | > - Oryginalna wiadomość - | > Od: "Simon Peyton-Jones" | > Do: "Jan Stolarek" , "Gabor Greif" | | > DW: ghc-devs@haskell.org | > Wysłane: czwartek, 22 sierpień 2013 13:40:09 | > Temat: RE: Changes to primops break libraries (was Re: 7.8 Feature | window) | > | > Jan | > | > Four things: | > | > | •Six primops are an exception to the rules above: sameMutableArray#, | > | sameMutableByteArray#, sameMutableArrayArray#, sameMutVar#, | sameMVar# | > | and sameTVar#. Their names have remained the same as before and new | > | wrappers created for them lack # at the end of their name. We made | that | > | decission because this naming feels more consistent and these | primops | > | are rarely used so we expect that they won't break a lot of existing | > | code. | > | > 1. Why do you say "this naming feels more consistent"? Consistent | with what? I'd expect sameTVar# to return a Bool, just like ==#. | > | > I'd prefer to say "just import PrimWrappers" than to say "just import | PrimWrapper and change the names of these six functions". I don’t | really see a clear distinction at all. | > | > 2. The module name PrimWrappers is terrible, because it's so close to | PrimopWrappers, which is machine generated. Lots of scope for confusion. | How about CmpOpWrappers or BoolOpWrappers? Any opinions from other ghc- | devs? | > | > 3. Could you add a section "Breaking changes" to | http://ghc.haskell.org/trac/ghc/wiki/PrimBool to explain what to change. | Currently it's buried (in bold I know) in "Implementation details" which | is not where I'd look as a library author. | > | > 4. Can the release notes | http://ghc.haskell.org/trac/ghc/browser/docs/users_guide/7.8.1-notes.xml | perhaps refer to the wiki page? That gives much more background. | Library authors will find that helpful. | > | > So long as we get these choices fixed for 7.8 we are fine. | > | > Simon | > | > ___ | > ghc-devs mailing list | > ghc-devs@haskell.org | > http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Changes to primops break libraries (was Re: 7.8 Feature window)
I think that's a pretty good idea. It's not just a hack... it makes sense even if you ignore the issues of managing the transition. Maybe GHC.Prim.Builtin for the machine-generated not-written-in-Haskell operations. Jan would you like to try it? Simon | -Original Message- | From: Geoffrey Mainland [mailto:mainl...@apeiron.net] | Sent: 22 August 2013 16:18 | To: Jan Stolarek | Cc: Simon Peyton-Jones; ghc-devs@haskell.org | Subject: Re: Changes to primops break libraries (was Re: 7.8 Feature | window) | | This is not a completely serious suggestions, but... If we moved the | magic GHC.Prim module to GHC.Prim.Base or something, then we could move | GHC.PrimWrappers to GHC.Prim, have it import GHC.Prim.Base, and, | assuming that we use Simon PJ's naming convention, (I think) no code | would have to change. | | Geoff | | On 08/22/2013 03:49 PM, Jan Stolarek wrote: | > I created a wiki page that describes the upgrade process in two easy | steps: | > | > http://ghc.haskell.org/trac/ghc/wiki/NewPrimopsInGHC7.8 | > | > I also added link to this page in the release notes. Simon, does this | address points 3 & 4 of your mail? Of course aside from the fact that if | we change name of GHC.PrimWrappers module than these page will need to | be updated accordingly. | > | > Janek | > | > - Oryginalna wiadomość - | > Od: "Simon Peyton-Jones" | > Do: "Jan Stolarek" , "Gabor Greif" | | > DW: ghc-devs@haskell.org | > Wysłane: czwartek, 22 sierpień 2013 13:40:09 | > Temat: RE: Changes to primops break libraries (was Re: 7.8 Feature | window) | > | > Jan | > | > Four things: | > | > | •Six primops are an exception to the rules above: sameMutableArray#, | > | sameMutableByteArray#, sameMutableArrayArray#, sameMutVar#, | sameMVar# | > | and sameTVar#. Their names have remained the same as before and new | > | wrappers created for them lack # at the end of their name. We made | that | > | decission because this naming feels more consistent and these | primops | > | are rarely used so we expect that they won't break a lot of existing | > | code. | > | > 1. Why do you say "this naming feels more consistent"? Consistent | with what? I'd expect sameTVar# to return a Bool, just like ==#. | > | > I'd prefer to say "just import PrimWrappers" than to say "just import | PrimWrapper and change the names of these six functions". I don’t | really see a clear distinction at all. | > | > 2. The module name PrimWrappers is terrible, because it's so close to | PrimopWrappers, which is machine generated. Lots of scope for confusion. | How about CmpOpWrappers or BoolOpWrappers? Any opinions from other ghc- | devs? | > | > 3. Could you add a section "Breaking changes" to | http://ghc.haskell.org/trac/ghc/wiki/PrimBool to explain what to change. | Currently it's buried (in bold I know) in "Implementation details" which | is not where I'd look as a library author. | > | > 4. Can the release notes | http://ghc.haskell.org/trac/ghc/browser/docs/users_guide/7.8.1-notes.xml | perhaps refer to the wiki page? That gives much more background. | Library authors will find that helpful. | > | > So long as we get these choices fixed for 7.8 we are fine. | > | > Simon | > | > ___ | > ghc-devs mailing list | > ghc-devs@haskell.org | > http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Changes to primops break libraries (was Re: 7.8 Feature window)
This is not a completely serious suggestions, but... If we moved the magic GHC.Prim module to GHC.Prim.Base or something, then we could move GHC.PrimWrappers to GHC.Prim, have it import GHC.Prim.Base, and, assuming that we use Simon PJ's naming convention, (I think) no code would have to change. Geoff On 08/22/2013 03:49 PM, Jan Stolarek wrote: > I created a wiki page that describes the upgrade process in two easy steps: > > http://ghc.haskell.org/trac/ghc/wiki/NewPrimopsInGHC7.8 > > I also added link to this page in the release notes. Simon, does this address > points 3 & 4 of your mail? Of course aside from the fact that if we change > name of GHC.PrimWrappers module than these page will need to be updated > accordingly. > > Janek > > - Oryginalna wiadomość - > Od: "Simon Peyton-Jones" > Do: "Jan Stolarek" , "Gabor Greif" > DW: ghc-devs@haskell.org > Wysłane: czwartek, 22 sierpień 2013 13:40:09 > Temat: RE: Changes to primops break libraries (was Re: 7.8 Feature window) > > Jan > > Four things: > > | •Six primops are an exception to the rules above: sameMutableArray#, > | sameMutableByteArray#, sameMutableArrayArray#, sameMutVar#, sameMVar# > | and sameTVar#. Their names have remained the same as before and new > | wrappers created for them lack # at the end of their name. We made that > | decission because this naming feels more consistent and these primops > | are rarely used so we expect that they won't break a lot of existing > | code. > > 1. Why do you say "this naming feels more consistent"? Consistent with what? > I'd expect sameTVar# to return a Bool, just like ==#. > > I'd prefer to say "just import PrimWrappers" than to say "just import > PrimWrapper and change the names of these six functions". I don’t really see > a clear distinction at all. > > 2. The module name PrimWrappers is terrible, because it's so close to > PrimopWrappers, which is machine generated. Lots of scope for confusion. How > about CmpOpWrappers or BoolOpWrappers? Any opinions from other ghc-devs? > > 3. Could you add a section "Breaking changes" to > http://ghc.haskell.org/trac/ghc/wiki/PrimBool to explain what to change. > Currently it's buried (in bold I know) in "Implementation details" which is > not where I'd look as a library author. > > 4. Can the release notes > http://ghc.haskell.org/trac/ghc/browser/docs/users_guide/7.8.1-notes.xml > perhaps refer to the wiki page? That gives much more background. Library > authors will find that helpful. > > So long as we get these choices fixed for 7.8 we are fine. > > Simon > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Changes to primops break libraries (was Re: 7.8 Feature window)
You're right Simon - I didn't thought about ltFloat and that my idea of "consistency" breaks there. Janek - Oryginalna wiadomość - Od: "Simon Peyton-Jones" Do: "Jan Stolarek" DW: ghc-devs@haskell.org, "Gabor Greif" 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. Simon | | Janek | | - Oryginalna wiadomość - | Od: "Jan Stolarek" | Do: "Simon Peyton-Jones" | DW: ghc-devs@haskell.org, "Gabor Greif" | 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
Re: Changes to primops break libraries (was Re: 7.8 Feature window)
I created a wiki page that describes the upgrade process in two easy steps: http://ghc.haskell.org/trac/ghc/wiki/NewPrimopsInGHC7.8 I also added link to this page in the release notes. Simon, does this address points 3 & 4 of your mail? Of course aside from the fact that if we change name of GHC.PrimWrappers module than these page will need to be updated accordingly. Janek - Oryginalna wiadomość - Od: "Simon Peyton-Jones" Do: "Jan Stolarek" , "Gabor Greif" DW: ghc-devs@haskell.org Wysłane: czwartek, 22 sierpień 2013 13:40:09 Temat: RE: Changes to primops break libraries (was Re: 7.8 Feature window) Jan Four things: | •Six primops are an exception to the rules above: sameMutableArray#, | sameMutableByteArray#, sameMutableArrayArray#, sameMutVar#, sameMVar# | and sameTVar#. Their names have remained the same as before and new | wrappers created for them lack # at the end of their name. We made that | decission because this naming feels more consistent and these primops | are rarely used so we expect that they won't break a lot of existing | code. 1. Why do you say "this naming feels more consistent"? Consistent with what? I'd expect sameTVar# to return a Bool, just like ==#. I'd prefer to say "just import PrimWrappers" than to say "just import PrimWrapper and change the names of these six functions". I don’t really see a clear distinction at all. 2. The module name PrimWrappers is terrible, because it's so close to PrimopWrappers, which is machine generated. Lots of scope for confusion. How about CmpOpWrappers or BoolOpWrappers? Any opinions from other ghc-devs? 3. Could you add a section "Breaking changes" to http://ghc.haskell.org/trac/ghc/wiki/PrimBool to explain what to change. Currently it's buried (in bold I know) in "Implementation details" which is not where I'd look as a library author. 4. Can the release notes http://ghc.haskell.org/trac/ghc/browser/docs/users_guide/7.8.1-notes.xml perhaps refer to the wiki page? That gives much more background. Library authors will find that helpful. So long as we get these choices fixed for 7.8 we are fine. Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
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. Simon | | Janek | | - Oryginalna wiadomość - | Od: "Jan Stolarek" | Do: "Simon Peyton-Jones" | DW: ghc-devs@haskell.org, "Gabor Greif" | 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
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 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" Do: "Simon Peyton-Jones" DW: ghc-devs@haskell.org, "Gabor Greif" 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
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
RE: Changes to primops break libraries (was Re: 7.8 Feature window)
Jan Four things: | •Six primops are an exception to the rules above: sameMutableArray#, | sameMutableByteArray#, sameMutableArrayArray#, sameMutVar#, sameMVar# | and sameTVar#. Their names have remained the same as before and new | wrappers created for them lack # at the end of their name. We made that | decission because this naming feels more consistent and these primops | are rarely used so we expect that they won't break a lot of existing | code. 1. Why do you say "this naming feels more consistent"? Consistent with what? I'd expect sameTVar# to return a Bool, just like ==#. I'd prefer to say "just import PrimWrappers" than to say "just import PrimWrapper and change the names of these six functions". I don’t really see a clear distinction at all. 2. The module name PrimWrappers is terrible, because it's so close to PrimopWrappers, which is machine generated. Lots of scope for confusion. How about CmpOpWrappers or BoolOpWrappers? Any opinions from other ghc-devs? 3. Could you add a section "Breaking changes" to http://ghc.haskell.org/trac/ghc/wiki/PrimBool to explain what to change. Currently it's buried (in bold I know) in "Implementation details" which is not where I'd look as a library author. 4. Can the release notes http://ghc.haskell.org/trac/ghc/browser/docs/users_guide/7.8.1-notes.xml perhaps refer to the wiki page? That gives much more background. Library authors will find that helpful. So long as we get these choices fixed for 7.8 we are fine. Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Changes to primops break libraries (was Re: 7.8 Feature window)
> Hmm, almost, but I get now: > (...) > How to repackage Int# to Bool? Oh dear... that's that 5% :) You just want sameMutableArray instead of sameMutableArray#. There will be problems with sameMVar and so on (if primitive uses them - I don't remember), but that's fixed in a similar way. A quick look at bottom of ghc-prim/GHC/PrimWrappers.hs will tell you what's going on with these functions. Also, from the wiki: •Six primops are an exception to the rules above: sameMutableArray#, sameMutableByteArray#, sameMutableArrayArray#, sameMutVar#, sameMVar# and sameTVar#. Their names have remained the same as before and new wrappers created for them lack # at the end of their name. We made that decission because this naming feels more consistent and these primops are rarely used so we expect that they won't break a lot of existing code. I hope this helps. Janek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Changes to primops break libraries (was Re: 7.8 Feature window)
On 8/21/13, Jan Stolarek wrote: > Hi Gabor, > >> I get these errors when building a cabal package: >> (...) >> I guess this is related to those changes. > Yes, that's because of my patches. > >> If yes, what to do next? Contact the 'primitive' maintainer? > It's just like with any other backwards-incompatible changes in GHC - > package maintainers need to fix their packages so they work with the new > version of GHC. My patch is expected to break stuff, though in 95% fix > should be very simple - add 'import GHC.PrimWrappers'. See wiki for more Hmm, almost, but I get now: Data/Primitive/Array.hs:110:5: Couldn't match expected type ?Bool? with actual type ?Int#? In the expression: sameMutableArray# arr# brr# In an equation for ?sameMutableArray?: sameMutableArray (MutableArray arr#) (MutableArray brr#) = sameMutableArray# arr# brr# Failed to install primitive-0.5.0.1 How to repackage Int# to Bool? Thanks, Gabor > detail: http://ghc.haskell.org/trac/ghc/wiki/PrimBool#Implementationdetails > > Janek > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
