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

On 8/20/13, Jan Stolarek 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@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

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

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

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

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

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

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

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

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

On 26/08/13 09:56, Gregory Collins wrote:

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

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

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

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:mainland@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

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" 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@haskell.org] *On Behalf Of *Dr. ÉRDI Gergo *Sent:* 21 August 2013 01:56 *To:* Austin Seipp *Cc:* ghc-devs@haskell.org *Subject:* Re: 7.8 Feature window****

** **

On Aug 21, 2013 1:05 AM, "Austin Seipp" 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****

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 mailto:aseipp@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@haskell.org mailto: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