7.8 Feature window

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
37 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

Jan Stolarek
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" <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.

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




Reply | Threaded
Open this post in threaded view
|

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

Geoffrey Mainland
In reply to this post by Jan Stolarek
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" <simonpj at microsoft.com>
> Do: "Jan Stolarek" <jan.stolarek at p.lodz.pl>, "Gabor Greif" <ggreif at gmail.com>
> DW: ghc-devs at 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs




Reply | Threaded
Open this post in threaded view
|

7.8 Feature window

Luite Stegeman
In reply to this post by Austin Seipp-4
In addition to the Hooks patch (see other mail on this post) I have a few
minor updates to support GHCJS that I think are pretty uncontroversial:

1. Add a WayCustom to the Ways type in DynFlags to make custom tags. We use
this to generate native code (.o, .hi) and JS code (.js_o, .js_hi) in the
same dir. This way we have a multitarget compiler that can load the native
code for TH.
2. Add "foreign import javascript" to the FFI grammar and a JavaScriptFFI
extension to enable it.
3. Add an ArchJavaScript constructor, unsupported on the built-in NCG

Only thing remaining is that the 'safe' and 'unsafe' specs in the
javascript imports are actually misnomers, they should be named 'async' and
'sync' respectively, with 'sync' being the default.

There used to be more in the GHCJS patch, but the rest has now been
superceded with more general Hooks. This means that all GHCJS-specific
things have actually been removed from the patch (no more wired-in
ghcjs-prim package and JSRef type), so any JS backend could use the exact
same things, using Hooks to customize things its own way.

luite


On Tue, Aug 20, 2013 at 7:01 PM, Austin Seipp <aseipp at pobox.com> wrote:

> All,
>
> GHC 7.8's release is drawing near. We would like to make a release
> candidate sometime around ICFP, which will be in late September.
> Unfortunately that's just over a month a way, so the clock is ticking!
>
> The tree will need a few weeks of stabilization. After that, we will
> release an RC, and likely branch. Then things will roughly return to normal.
>
> The exact date for feature cutoff is not set yet (but I will follow up
> soon on this.) So, I'd like a show of hands and a quick 'check in' for
> outstanding work for 7.8. There are a few things we know for sure are - or
> were - tentatively scheduled for this release:
>
>  * SIMD improvements
>  * New Template Haskell
>  * Constraint solver for type naturals
>
> These are - as far as I'm aware - the largest outstanding features which
> not quite yet in HEAD.
>
> For the release, we would like to minimize 'disruptive' features, because
> 7.8 already has many large changes. In particular, Dynamic GHCi and dynamic
> builds will likely prove the biggest challenge 'in the field', so we would
> like plenty of time to stress this as best we can for the RC, and the
> release itself.
>
> There are some things which we are fairly certain will not make it:
>
>  * Joachim's new newtype coercion implementation
>  * Adam's new record implementation
>
> There are some things I'm not very privvy to perhaps, but could still go
> in:
>
>  * Nicolas possibly had some optimisation improvements according to Simon.
>
>  * Edsko had a small patch for extended plugin functionality in HEAD, but
> Luite and Thomas also have input here. Status is uncertain.
>
>  * ERDI was working on pattern synonyms. I believe you were having some
> trouble with the implementation. Can someone help him if necessary?
>
> Finally, there are loose ends to tie off:
>
>  * I believe Simon and Jose were having discussions about the new Typeable
> implementation, regarding hand-written instances. This should be fine for
> 7.8 and is mostly some behavioral tweaking I think.
>
> I've undoubtedly missed things here. Please fill me in. :)
>
> Note that before the freeze, you should interpret 'disruptive' with your
> own good judgement. Smaller patches and improvements are certainly welcome
> as always, and you shouldn't wait on me to push something if you feel good
> about it. If you're ever unsure, just ask. Worst case is something gets
> backed out, but it's nothing we cannot come back to.
>
> --
> Regards,
> Austin - PGP: 4096R/0x91384671
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130822/801693f8/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

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

Simon Peyton Jones
In reply to this post by Geoffrey Mainland
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:mainland at apeiron.net]
| Sent: 22 August 2013 16:18
| To: Jan Stolarek
| Cc: Simon Peyton-Jones; ghc-devs at 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" <simonpj at microsoft.com>
| > Do: "Jan Stolarek" <jan.stolarek at p.lodz.pl>, "Gabor Greif"
| <ggreif at gmail.com>
| > DW: ghc-devs at 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 at haskell.org
| > http://www.haskell.org/mailman/listinfo/ghc-devs


Reply | Threaded
Open this post in threaded view
|

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

Jan Stolarek
Sure. I considered that idea at some point but it seemed a bit to drastic.

Janek

----- Oryginalna wiadomo?? -----
Od: "Simon Peyton-Jones" <simonpj at microsoft.com>
Do: "Geoffrey Mainland" <mainland at apeiron.net>, "Jan Stolarek" <jan.stolarek at p.lodz.pl>
DW: ghc-devs at 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:mainland at apeiron.net]
| Sent: 22 August 2013 16:18
| To: Jan Stolarek
| Cc: Simon Peyton-Jones; ghc-devs at 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" <simonpj at microsoft.com>
| > Do: "Jan Stolarek" <jan.stolarek at p.lodz.pl>, "Gabor Greif"
| <ggreif at gmail.com>
| > DW: ghc-devs at 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 at haskell.org
| > http://www.haskell.org/mailman/listinfo/ghc-devs




Reply | Threaded
Open this post in threaded view
|

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

Simon Marlow-7
In reply to this post by Simon Peyton Jones
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
>




Reply | Threaded
Open this post in threaded view
|

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

Jan Stolarek
> 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



Reply | Threaded
Open this post in threaded view
|

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

Simon Marlow-7
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




Reply | Threaded
Open this post in threaded view
|

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

Jan Stolarek
> 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



Reply | Threaded
Open this post in threaded view
|

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

Gregory Collins-3
In reply to this post by Simon Marlow-7
On Sun, Aug 25, 2013 at 9:47 PM, Simon Marlow <marlowsd at 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!

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 reeeeallly 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 <greg at gregorycollins.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130826/1022ba83/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

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

Simon Marlow-7
In reply to this post by Jan Stolarek
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




Reply | Threaded
Open this post in threaded view
|

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

Jan Stolarek
> 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



Reply | Threaded
Open this post in threaded view
|

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

Simon Marlow-7
In reply to this post by Gregory Collins-3
On 26/08/13 09:56, Gregory Collins wrote:

>
> On Sun, Aug 25, 2013 at 9:47 PM, Simon Marlow <marlowsd at gmail.com
> <mailto:marlowsd at 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 reeeeallly 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




Reply | Threaded
Open this post in threaded view
|

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

Simon Marlow-7
In reply to this post by Jan Stolarek
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




Reply | Threaded
Open this post in threaded view
|

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

Herbert Valerio Riedel
In reply to this post by Gregory Collins-3
On 2013-08-26 at 10:56:15 +0200, Gregory Collins wrote:

> On Sun, Aug 25, 2013 at 9:47 PM, Simon Marlow <marlowsd at 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!

...btw, do we actually know which (or how many) packages are affected?



Reply | Threaded
Open this post in threaded view
|

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

Jan Stolarek
In reply to this post by Simon Marlow-7
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





Reply | Threaded
Open this post in threaded view
|

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

Gregory Collins-3
In reply to this post by Herbert Valerio Riedel
On Mon, Aug 26, 2013 at 12:51 PM, Herbert Valerio Riedel <hvr at gnu.org>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 <greg at gregorycollins.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130826/de106f08/attachment.htm>

12