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
|

7.8 Feature window

Austin Seipp-4
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130820/2b3be35c/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

7.8 Feature window

Simon Peyton Jones
Details here: do please modify directly:
http://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8

S
From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Austin Seipp
Sent: 20 August 2013 18:01
To: ghc-devs at haskell.org
Subject: 7.8 Feature window

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130820/b5d649f8/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

7.8 Feature window

Jan Stolarek
> Details here: do please modify directly:
> http://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8
Feature I was working on has been merged into HEAD. Should I remove it from the list?

Janek



Reply | Threaded
Open this post in threaded view
|

7.8 Feature window

Austin Seipp-4
Yes - but leavae it to me. I'll do some cleanup since some of Richard's
work was also merged.


On Tue, Aug 20, 2013 at 12:14 PM, Jan Stolarek <jan.stolarek at p.lodz.pl>wrote:

> > Details here: do please modify directly:
> > http://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8
> Feature I was working on has been merged into HEAD. Should I remove it
> from the list?
>
> Janek
>



--
Regards,
Austin - PGP: 4096R/0x91384671
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130820/728beb96/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

7.8 Feature window

Iavor Diatchki
In reply to this post by Austin Seipp-4
Hello,

For the constraint solver for type naturals: I think we should certainly
have some form of it in 7.8, even if it is the really simple version that
just knows things like: 5 + 3 = 8.    There is a bit of work to be done to
catch up the type-nats branch to HEAD, mainly to do with Richard's changes
about roles, I believe.  I am back from vacation from tomorrow, and I think
I'll have quite a bit of time to hack on GHC so I'll catch up the branch,
and prepare it for merging (i.e., rebase things so that the main
functionality is split into one or two patches).

-Iavor


On Tue, Aug 20, 2013 at 10:01 AM, 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/20130820/8d02acde/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

7.8 Feature window

Dr. ERDI Gergo
In reply to this post by Austin Seipp-4
On Aug 21, 2013 1:05 AM, "Austin Seipp" <aseipp at pobox.com> wrote:

>  * ERDI was working on pattern synonyms. I believe you were having some
trouble with the implementation. Can someone help him if necessary?

Hi,

I've updated the Trac ticket with the latest status of my work. There are
only two loose ends remaining, and my hope is that the second one will turn
out to be some trivial oversight on my part.

How long does the patch review process usually take? Just so I can factor
that in when thinking of getting this into 7.8.0.

Bye,
Gergo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130821/2f819a06/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

7.8 Feature window

Gabor Greif-2
In reply to this post by Jan Stolarek
On 8/20/13, Jan Stolarek <jan.stolarek at p.lodz.pl> wrote:
>> Details here: do please modify directly:
>> http://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8
> Feature I was working on has been merged into HEAD. Should I remove it from
> the list?

Hello Jan,

I get these errors when building a cabal package:

Data/Primitive/Types.hs:58:24:
    Not in scope: ?leAddr#?
    Perhaps you meant one of these:
      ?leAddrI#? (imported from GHC.Prim),
      ?ltAddrI#? (imported from GHC.Prim),
      ?neAddrI#? (imported from GHC.Prim)
Failed to install primitive-0.5.0.1
cabal: Error: some packages failed to install:
primitive-0.5.0.1 failed during the building phase. The exception was:
ExitFailure 1
vector-0.10.9 depends on primitive-0.5.0.1 which failed to install.
make: *** [vector] Error 1

I guess this is related to those changes.

If yes, what to do next? Contact the 'primitive' maintainer?

Cheers,

    Gabor


>
> 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
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 detail: http://ghc.haskell.org/trac/ghc/wiki/PrimBool#Implementationdetails

Janek



Reply | Threaded
Open this post in threaded view
|

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

Gabor Greif-2
On 8/21/13, Jan Stolarek <jan.stolarek at p.lodz.pl> 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
>



Reply | Threaded
Open this post in threaded view
|

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

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



Reply | Threaded
Open this post in threaded view
|

7.8 Feature window

Ryan Newton
In reply to this post by Austin Seipp-4
Hi all,

It is not merged into "master" presently but I would like to propose the
three new primops that are on the "atomics" branch for inclusion in 7.8.
 These are pretty much completely apart from everything else and don't
break any existing code.

For the public library that exposes these things ("atomic-primops") it will
be a great boon to be able to depend on them in  7.8 and not have to wait
yet another release cycle [1].

Best,
  -Ryan

[1] P.S. 7.8 will already be a breaking change to atomic-primops, because
of the change in CMM syntax.  So if it has to be #ifdef'd anyway, we might
as well go straight to the Right Thing rather than having a proliferation
of intermediate hacks.




On Tue, Aug 20, 2013 at 1: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/20130821/3013140c/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

7.8 Feature window

Simon Peyton Jones
In reply to this post by Dr. ERDI Gergo
How long does the patch review process usually take? Just so I can factor that in when thinking of getting this into 7.8.0.
There are two issues:

1.   Is the design good?  Does the additional language complexity pay its way?  Is the implementation reasonably simple, or unreasonably complicated?

2.    Is the actual patch good (well-implemented, well-documented, etc)

(2) is relatively straightforward, but this feature is a "big" one.   I'd like to get a bit of feedback from our community.

The Trac page sketches the design, but I bet you have come across some subtleties as you implemented it.  (Exports for one.)  Would you be willing to expand the design specification (as seen by the programmer) to be as complete as possible?   Include some examples.  This would best be done on the Trac wiki rather than in the ticket itself.  Most of text can come from the existing writeup, but I expect you have more to add.   (Or maybe not... maybe it all turned out to be very simple.)

Once we have that we can send email to ghc-users pointing to the spec and asking what they think.  Lots of smart people there who may well have Good Ideas.

My gut feel is that, rather than rushing to throw this into 7.8, we should take a little while to think about it.  Everything else we are planning for 7.8 has been in gestation for much longer.

Any opinions from other ghc-devs?  http://ghc.haskell.org/trac/ghc/ticket/5144

Talk later this week.

Simon



From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Dr. ?RDI Gergo
Sent: 21 August 2013 01:56
To: Austin Seipp
Cc: ghc-devs at haskell.org
Subject: Re: 7.8 Feature window


On Aug 21, 2013 1:05 AM, "Austin Seipp" <aseipp at pobox.com<mailto:aseipp at pobox.com>> wrote:

>  * ERDI was working on pattern synonyms. I believe you were having some trouble with the implementation. Can someone help him if necessary?

Hi,

I've updated the Trac ticket with the latest status of my work. There are only two loose ends remaining, and my hope is that the second one will turn out to be some trivial oversight on my part.

How long does the patch review process usually take? Just so I can factor that in when thinking of getting this into 7.8.0.

Bye,
Gergo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130821/a1838728/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

7.8 Feature window

Bryan O'Sullivan
In reply to this post by Austin Seipp-4
On Tue, Aug 20, 2013 at 10:01 AM, Austin Seipp <aseipp at pobox.com> wrote:

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

I have some additional optimizations to the new I/O manager that I'm hoping
I can finish up. Based on current numbers, they improve networking
performance by a further 10% on top of Andreas and Kazu's recent efforts.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130821/7bdf60b3/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

7.8 Feature window

Dr. ERDI Gergo
In reply to this post by Simon Peyton Jones
I've updated the Wiki page to better match what I'm implementing. Apart
from reorganizing the page slightly, all I really had to change was the
paragraph on exporting/importing.

Should I explicitly mark parts of the page that are not yet implemented?
I'd think the page should stay to be about what we aim for, not what we
happen to have as of some random date.
On Aug 22, 2013 12:09 AM, "Simon Peyton-Jones" <simonpj at microsoft.com>
wrote:

>  How long does the patch review process usually take? Just so I can
> factor that in when thinking of getting this into 7.8.0.****
>
> There are two issues:****
>
> **1.   **Is the design good?  Does the additional language complexity pay
> its way?  Is the implementation reasonably simple, or unreasonably
> complicated?****
>
> **2.   ** Is the actual patch good (well-implemented, well-documented,
> etc)****
>
> ** **
>
> (2) is relatively straightforward, but this feature is a ?big? one.   I?d
> like to get a bit of feedback from our community.****
>
> ** **
>
> The Trac page sketches the design, but I bet you have come across some
> subtleties as you implemented it.  (Exports for one.)  Would you be willing
> to expand the design specification (as seen by the programmer) to be as
> complete as possible?   Include some examples.  This would best be done on
> the Trac wiki rather than in the ticket itself.  Most of text can come from
> the existing writeup, but I expect you have more to add.   (Or maybe not...
> maybe it all turned out to be very simple.)****
>
> ** **
>
> Once we have that we can send email to ghc-users pointing to the spec and
> asking what they think.  Lots of smart people there who may well have Good
> Ideas.****
>
> ** **
>
> My gut feel is that, rather than rushing to throw this into 7.8, we should
> take a little while to think about it.  Everything else we are planning for
> 7.8 has been in gestation for much longer.****
>
> ** **
>
> Any opinions from other ghc-devs?
> http://ghc.haskell.org/trac/ghc/ticket/5144****
>
> ** **
>
> Talk later this week.****
>
>
> Simon****
>
> ** **
>
> ** **
>
> ** **
>
> *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Dr.
> ?RDI Gergo
> *Sent:* 21 August 2013 01:56
> *To:* Austin Seipp
> *Cc:* ghc-devs at haskell.org
> *Subject:* Re: 7.8 Feature window****
>
> ** **
>
>
> On Aug 21, 2013 1:05 AM, "Austin Seipp" <aseipp at pobox.com> wrote:****
>
> >  * ERDI was working on pattern synonyms. I believe you were having some
> trouble with the implementation. Can someone help him if necessary?****
>
> Hi,****
>
> I've updated the Trac ticket with the latest status of my work. There are
> only two loose ends remaining, and my hope is that the second one will turn
> out to be some trivial oversight on my part. ****
>
> How long does the patch review process usually take? Just so I can factor
> that in when thinking of getting this into 7.8.0.****
>
> Bye,
> Gergo****
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130822/f2af85a9/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

7.8 Feature window

Simon Marlow-7
In reply to this post by Ryan Newton
On 21/08/13 16:11, Ryan Newton wrote:

> Hi all,
>
> It is not merged into "master" presently but I would like to propose the
> three new primops that are on the "atomics" branch for inclusion in 7.8.
>   These are pretty much completely apart from everything else and don't
> break any existing code.
>
> For the public library that exposes these things ("atomic-primops") it
> will be a great boon to be able to depend on them in  7.8 and not have
> to wait yet another release cycle [1].

I skimmed the patches and they look OK to me (modulo the tabs).

Of course longer term we should have MachOps for the low-level atomic
operations and get rid of the two layers of function call in these primops.

Cheers,
        Simon



> Best,
>    -Ryan
>
> [1] P.S. 7.8 will already be a breaking change to atomic-primops,
> because of the change in CMM syntax.  So if it has to be #ifdef'd
> anyway, we might as well go straight to the Right Thing rather than
> having a proliferation of intermediate hacks.
>
>
>
>
> On Tue, Aug 20, 2013 at 1:01 PM, Austin Seipp <aseipp at pobox.com
> <mailto: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 <mailto:ghc-devs at haskell.org>
>     http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
>
>
> _______________________________________________
> 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 Peyton Jones
In reply to this post by Jan Stolarek
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

Reply | Threaded
Open this post in threaded view
|

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

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

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

Simon Peyton Jones
| 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)

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



12