- ghc-devs - Haskell.org

RE: Haskell Support on Windows
by Simon Peyton Jones 01 Apr '14

01 Apr '14

| I've been getting the impression that a lot of the stickier GHC bugs are | Windows specific, while very few GHC hackers actually use Windows, other | than to ensure that GHC works on it. ... | Perhaps it should be "demoted" to second-tier GHC support as well, at | least to the extent that Windows bugs won't hold up a release? That's true. But many, many people *use* GHC on Windows. It would be terribly sad to abandon them. What we need is more developers to volunteer to help look after the Windows version of GHC. One or two are doing so, but we need more. Please! Simon

1 0

RE: Gearing up (again) for the next release: 2014.2.0.0
by Simon Peyton Jones 31 Mar '14

31 Mar '14

| If I've understood #8736 correctly, GHCi on Windows can't load modules | that | were compiled with --dynamic-too. That's a pretty nasty regression, as | --dynamic-too will now be the default for anything used by TH. Well, five weeks ago we marked the ticket as "not a release blocker". No one commented. And it's not a regression, is it? I don't think -dynamic-too existed in 7.6. We'd welcome help with this. There is some reason it's not straightforward to fix, but I've forgotten what it is. Simon | -----Original Message----- | From: Libraries [mailto:libraries-bounces@haskell.org] On Behalf Of harry | Sent: 31 March 2014 09:21 | To: libraries(a)haskell.org | Subject: RE: Gearing up (again) for the next release: 2014.2.0.0 | | Simon Peyton Jones wrote | > We have not begun to think about when to release 7.8.2. It’ll depend | on | > what issues show up in 7.8.1 and how urgent they seem to be. We have | > delayed 7.8.1 for ages, and given masses of warning about the release, | so | > I’d be sad if there are known, show-stopping bugs in it that we already | > know about. If there really really really are, maybe we should delay | > 7.8.1 further. But that process can go on indefinitely (as we have | > already seen), so I’m pretty reluctant. | > | > But I’d certainly listen to a consensus view from the HP team. You | > represent our customers. | | If I've understood #8736 correctly, GHCi on Windows can't load modules | that | were compiled with --dynamic-too. That's a pretty nasty regression, as | --dynamic-too will now be the default for anything used by TH. | | | | -- | View this message in context: | http://haskell.1045720.n5.nabble.com/Gearing-up-again-for-the-next- | release-2014-2-0-0-tp5746660p5746686.html | Sent from the Haskell - Libraries mailing list archive at Nabble.com. | _______________________________________________ | Libraries mailing list | Libraries(a)haskell.org | http://www.haskell.org/mailman/listinfo/libraries

1 0

Looks like I broke the build. Fixing <eom>
by Johan Tibell 29 Mar '14

29 Mar '14

2 7

Re: We need to add role annotations for 7.8
by Mark Lentczner 28 Mar '14

28 Mar '14

Thank you to everyone who has been helping me understand this issue in greater depth. *tl;dr: As long as we don't expect any libraries beyond to core to annotate, I'm cool. This presumes that the extra safety isn't, in practice, dependent on transitive adoption by libraries. It also implies that representational is the only possible default, and that there can be no migration from it.* My approach to thinking about this is guided by thinking about supporting an eco-system with 1000s of libraries (hackage), a few dozen of which are heavily promoted (the platform), and a small set that are closely tied to the compiler (the core). The availability, speed of release, motivation, and even skill of the the developers varies widely over that range. I also think about the various "stances" of different developers: - *End developer*: makes use of libraries, but just builds apps - *Internal developer*: makes libraries for internal use in a project - *Casual library writer*: makes libraries, primarily for their own needs, but distributed on hackage - *Popular library writer:* actively maintains libraries which are widely used - *Core library writer: *maintainer of a core package that stays in lock step with the compiler Then, I think about, for each of these, what is the effect on a new feature on them, their existing code, and future code? Does it affect them only if they are using the feature? If they aren't using the feature? For library writers, how does the feature affect clients? If a client wants to use a feature, under what conditions does the library need to do something? This last issue of the "transitivity" the feature is often the biggest concern. *Given that... onto type roles:* The default of *representational* is the only option, because a default of *nominal* would require far too many developers to have to update their code. I don't believe that we can ever migrate to *nominal* as default. The feature implies that any abstract data type that uses a type parameter in certain ways needs annotate to get the full safety afforded now afforded. However, without annotation, the data type is still no worse off than it was before (there is added safety, but not perhaps relevant to the stand point of the library writer). Further, this (pre-existing) non-safety isn't likely a huge concern. Making sure the docs take the tone that most developers need to nothing, and when developers need to be concerned seems like an important way to ensure the right outcome. A key question here is transitivity: Is it possible for module A to not annotate a type, and then have module B by a different author use the type in A in another abstract type, that *is* annotated, and get the benefit. Seems the answer is "partially". If the answer were "no", then use of the feature would be dependent on transitive adoption, and that is where the big burden on developers comes from. The degree to which we believe this "partially" is important: If we are willing to believe that the only library writers we care about doing this are those in the core, then fine. In this case we shouldn't feel compelled to suggest to library writers that they annotate, ever. I'm good with this. If the team here thinks otherwise, that we need to start a campaign to get every library writer to eventually annotate, then I have deep objections. I read the paper, and understand how the authors felt the syntax options were all less than perfect, and choose what they did. But that choice, perhaps unwittingly, the implication that it forces -XCPP on all libraries except perhaps some of the core. This is because they all need to support previous compilers. So, a one line annotation has turned into an ugly beast, and perhaps added -XCPP where there was none, which is really unfortunate. (I, like many, consider it a defeat when one has to resort to -XCPP.) It seems to me that the paper didn't really consider less-perfect, heuristic solutions. It might have had significantly less impact on library writers were some heuristic (no constructors exported? has any type constraint on the parameter? etc..) might have allowed most data types to go without annotation at the cost of a few (where *nominal* was incorrectly inferred) requiring immediate action. In this situation, a non-language feature (pragma or other device) might have been more palatable. Finally, on the choice of terms, *nominal*, *representational*, and *phantom* all seem like clear, self-explanatory choices to me. - Mark

3 5

help understanding the validate_build_xhtml failure of ./validate for my CPP patch
by Carter Schonwald 28 Mar '14

28 Mar '14

Hey all, I'm trying to get my CPP_Setttings patch to validate, and i'm trying to understand why my validate is failing. At this point im stumped and I really could use some help! I'd appreciate some assistance digging into this, the ticket in question is https://ghc.haskell.org/trac/ghc/ticket/8683#comment:50 my current set of patches is https://github.com/cartazio/ghc/compare/ghc:ghc-7.8...rb_cpp_settings(rebas… on top of current 7.8 branch) and the confusing error in question is == Start post-install package check Timestamp 2014-03-23 17:32:46 UTC for /Users/carter/Desktop/repoScratcher/ghc/bindisttest/install dir/lib/ghc-7.8.0.20140323/package.conf.d/package.cache Timestamp 2014-03-23 17:32:46 UTC for /Users/carter/Desktop/repoScratcher/ghc/bindisttest/install dir/lib/ghc-7.8.0.20140323/package.conf.d (same as cache) using cache: /Users/carter/Desktop/repoScratcher/ghc/bindisttest/install dir/lib/ghc-7.8.0.20140323/package.conf.d/package.cache == End post-install package check ===--- building phase 0 /Applications/Xcode.app/Contents/Developer/usr/bin/make -r --no-print-directory -f ghc.mk phase=0 phase_0_builds make[1]: Nothing to be done for `phase_0_builds'. ===--- building phase 1 /Applications/Xcode.app/Contents/Developer/usr/bin/make -r --no-print-directory -f ghc.mk phase=1 phase_1_builds make[1]: Nothing to be done for `phase_1_builds'. ===--- building final phase /Applications/Xcode.app/Contents/Developer/usr/bin/make -r --no-print-directory -f ghc.mk phase=final validate_build_xhtml cd libraries/xhtml && "/Users/carter/Desktop/repoScratcher/ghc/bindisttest/install dir/bin/ghc" --make Setup [1 of 1] Compiling Main ( Setup.hs, Setup.o ) Linking Setup ... cd libraries/xhtml && ./Setup configure --with-ghc="/Users/carter/Desktop/repoScratcher/ghc/bindisttest/install dir/bin/ghc" --with-haddock="/Users/carter/Desktop/repoScratcher/ghc/bindisttest/install dir/bin/haddock" --enable-shared --disable-library-vanilla --disable-library-prof --global --builddir=dist-bindist --prefix="/Users/carter/Desktop/repoScratcher/ghc/bindisttest/install dir" Configuring xhtml-3000.2.1... cd libraries/xhtml && ./Setup build --builddir=dist-bindist Building xhtml-3000.2.1... Preprocessing library xhtml-3000.2.1... ghc: could not execute: make[1]: *** [validate_build_xhtml] Error 1 make: *** [validate_build_xhtml] Error 2 If someone could help me get to the bottom of this, I'd really really appreciate it. -Carter

2 2

Wired-in packages not found
by Maarten Faddegon 27 Mar '14

27 Mar '14

Dear GHC-devs, I want to experiment with the RTS of GHC but the compiler I built has problems finding some wired-in packages. How can I include these? This is what I did: * Download ghc-7.6.3 sources. * Make some changes in rts/ * ./configure && make * inplace/bin/ghc-stage2 --make my_example.lhs -v And this is the output produced by the last step: ... wired-in package ghc-prim mapped to ghc-prim-0.3.0.0-inplace wired-in package integer-gmp mapped to integer-gmp-0.5.0.0-inplace wired-in package base mapped to base-4.6.0.1-inplace wired-in package rts mapped to builtin_rts wired-in package template-haskell not found. wired-in package dph-seq not found. wired-in package dph-par not found. ... my_example.lhs:88:8: Could not find module `Language.Haskell.TH' Locations searched: Language/Haskell/TH.hs Language/Haskell/TH.lhs Thanks, Maarten Faddegon

4 7

Re: We need to add role annotations for 7.8
by Richard Eisenberg 27 Mar '14

27 Mar '14

Not for more than a passing mention. Using the name of the module to control the default makes me unhappy (should choice of name be relevant in the correctness / interpretation of a program?). Other heuristics (presence of constrained functions) seem quite fragile. Of everything said so far, I think the closest suggestion is to use constrained datatypes (like `data Ord a => Set a = ...`), but that mis-appropriates datatype contexts (which are silly) into something new and different, and so I personally don't think it's really viable. Following Mark's idea of breaking this problem up into more manageable chunks, I would want us to think about two separate (and conflicting, often) users: 1. Users of today's Haskell who have to update their code. 2. Users of Haskell in 10 years. Would users in group (2) like these heuristics? I doubt it. I think users in group (2) would probably most like a default of nominal with role annotations (in some concrete syntax). But, users in group (1) would hate a nominal default, so we have a compromise. Richard On Mar 26, 2014, at 11:40 AM, Casey McCann <cam(a)uptoisomorphism.net> wrote: > Were any rules considered along the lines of "Representational by > default if all the type's constructors are exported by a module not > named 'Internal', nominal by default otherwise"? Better would probably > include "exported by a module the package exposes" but that's > disgustingly non-local if it's even possible at all. The module name > thing is hacky to the extreme but at least it's a simple rule rather > than some obscure and opaque heuristics. > > Anyway, the goal of something like that would be not so much "figure > out what it should be", since that's impossible, but more "default to > nominal if and only if there's clear indication the user is already > thinking about restricting how the type is used". > > Not that I'm really even suggesting such a rule, just wondering if it > was discussed. > > - C. > > > On Tue, Mar 25, 2014 at 7:23 PM, Richard Eisenberg <eir(a)cis.upenn.edu> wrote: >> Hi Mark, >> >> I appreciate your analysis in terms of classes of users -- I think that is >> helpful for framing the discussion. >> >> About transitivity: I think we're in the clear here. Let's say package A >> exports types missing role annotations. If package B imports package A and >> wants to have the full safety afforded by roles, that is no problem >> whatsoever. Package B has annotations on its types (which may use package >> A's types) that may restrict certain parameters to be nominal, as >> appropriate. If package A had role annotations, it's quite possible that >> package B could omit some annotations (as role inference propagates nominal >> roles), but there is no problem inherent in this. (Indeed, if package A adds >> annotations in the future, package B would have redundant, but harmless, >> annotations.) So, I disagree with Mark's "partially" below -- I think we're >> fully OK in this regard. >> >> About heuristics: we briefly considered some, though there's no >> documentation of this anywhere. Specifically, we thought about giving >> nominal roles to parameters used in class constraints. The problem is, in >> the actual datatype definition, the constraints tend not to appear? Should >> we look around for other functions with constraints? That seems likely to be >> more confusing than helpful. Furthermore, I strongly don't like the idea of >> using heuristics to infer a feature such as this -- it can cause strange >> behavior and is hard to specify. >> >> Richard >> >> On Mar 25, 2014, at 11:09 AM, Mark Lentczner wrote: >> >> Thank you to everyone who has been helping me understand this issue in >> greater depth. >> >> tl;dr: As long as we don't expect any libraries beyond to core to annotate, >> I'm cool. This presumes that the extra safety isn't, in practice, dependent >> on transitive adoption by libraries. It also implies that representational >> is the only possible default, and that there can be no migration from it. >> >> My approach to thinking about this is guided by thinking about supporting an >> eco-system with 1000s of libraries (hackage), a few dozen of which are >> heavily promoted (the platform), and a small set that are closely tied to >> the compiler (the core). The availability, speed of release, motivation, and >> even skill of the the developers varies widely over that range. >> >> I also think about the various "stances" of different developers: >> >> End developer: makes use of libraries, but just builds apps >> Internal developer: makes libraries for internal use in a project >> Casual library writer: makes libraries, primarily for their own needs, but >> distributed on hackage >> Popular library writer: actively maintains libraries which are widely used >> Core library writer: maintainer of a core package that stays in lock step >> with the compiler >> >> Then, I think about, for each of these, what is the effect on a new feature >> on them, their existing code, and future code? Does it affect them only if >> they are using the feature? If they aren't using the feature? For library >> writers, how does the feature affect clients? If a client wants to use a >> feature, under what conditions does the library need to do something? This >> last issue of the "transitivity" the feature is often the biggest concern. >> >> Given that... onto type roles: >> >> The default of representational is the only option, because a default of >> nominal would require far too many developers to have to update their code. >> I don't believe that we can ever migrate to nominal as default. >> >> The feature implies that any abstract data type that uses a type parameter >> in certain ways needs annotate to get the full safety afforded now afforded. >> However, without annotation, the data type is still no worse off than it was >> before (there is added safety, but not perhaps relevant to the stand point >> of the library writer). Further, this (pre-existing) non-safety isn't likely >> a huge concern. Making sure the docs take the tone that most developers need >> to nothing, and when developers need to be concerned seems like an important >> way to ensure the right outcome. >> >> A key question here is transitivity: Is it possible for module A to not >> annotate a type, and then have module B by a different author use the type >> in A in another abstract type, that is annotated, and get the benefit. Seems >> the answer is "partially". If the answer were "no", then use of the feature >> would be dependent on transitive adoption, and that is where the big burden >> on developers comes from. >> >> The degree to which we believe this "partially" is important: If we are >> willing to believe that the only library writers we care about doing this >> are those in the core, then fine. In this case we shouldn't feel compelled >> to suggest to library writers that they annotate, ever. I'm good with this. >> If the team here thinks otherwise, that we need to start a campaign to get >> every library writer to eventually annotate, then I have deep objections. >> >> I read the paper, and understand how the authors felt the syntax options >> were all less than perfect, and choose what they did. But that choice, >> perhaps unwittingly, the implication that it forces -XCPP on all libraries >> except perhaps some of the core. This is because they all need to support >> previous compilers. So, a one line annotation has turned into an ugly beast, >> and perhaps added -XCPP where there was none, which is really unfortunate. >> (I, like many, consider it a defeat when one has to resort to -XCPP.) >> >> It seems to me that the paper didn't really consider less-perfect, heuristic >> solutions. It might have had significantly less impact on library writers >> were some heuristic (no constructors exported? has any type constraint on >> the parameter? etc..) might have allowed most data types to go without >> annotation at the cost of a few (where nominal was incorrectly inferred) >> requiring immediate action. In this situation, a non-language feature >> (pragma or other device) might have been more palatable. >> >> Finally, on the choice of terms, nominal, representational, and phantom all >> seem like clear, self-explanatory choices to me. >> >> - Mark >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs(a)haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> >> >> >> _______________________________________________ >> Libraries mailing list >> Libraries(a)haskell.org >> http://www.haskell.org/mailman/listinfo/libraries >>

2 1

Re: We need to add role annotations for 7.8
by Carter Schonwald 26 Mar '14

26 Mar '14

I think something like that is on the table, at least for a future ghc release. I'm not sure if it made it into the patches for 7.8.1. But this was actually suggested on the relevant ticket last week. (I'm Afk otherwise id dig up the link) On Wednesday, March 26, 2014, Casey McCann <cam(a)uptoisomorphism.net> wrote: > Were any rules considered along the lines of "Representational by > default if all the type's constructors are exported by a module not > named 'Internal', nominal by default otherwise"? Better would probably > include "exported by a module the package exposes" but that's > disgustingly non-local if it's even possible at all. The module name > thing is hacky to the extreme but at least it's a simple rule rather > than some obscure and opaque heuristics. > > Anyway, the goal of something like that would be not so much "figure > out what it should be", since that's impossible, but more "default to > nominal if and only if there's clear indication the user is already > thinking about restricting how the type is used". > > Not that I'm really even suggesting such a rule, just wondering if it > was discussed. > > - C. > > > On Tue, Mar 25, 2014 at 7:23 PM, Richard Eisenberg <eir(a)cis.upenn.edu> > wrote: > > Hi Mark, > > > > I appreciate your analysis in terms of classes of users -- I think that > is > > helpful for framing the discussion. > > > > About transitivity: I think we're in the clear here. Let's say package A > > exports types missing role annotations. If package B imports package A > and > > wants to have the full safety afforded by roles, that is no problem > > whatsoever. Package B has annotations on its types (which may use package > > A's types) that may restrict certain parameters to be nominal, as > > appropriate. If package A had role annotations, it's quite possible that > > package B could omit some annotations (as role inference propagates > nominal > > roles), but there is no problem inherent in this. (Indeed, if package A > adds > > annotations in the future, package B would have redundant, but harmless, > > annotations.) So, I disagree with Mark's "partially" below -- I think > we're > > fully OK in this regard. > > > > About heuristics: we briefly considered some, though there's no > > documentation of this anywhere. Specifically, we thought about giving > > nominal roles to parameters used in class constraints. The problem is, in > > the actual datatype definition, the constraints tend not to appear? > Should > > we look around for other functions with constraints? That seems likely > to be > > more confusing than helpful. Furthermore, I strongly don't like the idea > of > > using heuristics to infer a feature such as this -- it can cause strange > > behavior and is hard to specify. > > > > Richard > > > > On Mar 25, 2014, at 11:09 AM, Mark Lentczner wrote: > > > > Thank you to everyone who has been helping me understand this issue in > > greater depth. > > > > tl;dr: As long as we don't expect any libraries beyond to core to > annotate, > > I'm cool. This presumes that the extra safety isn't, in practice, > dependent > > on transitive adoption by libraries. It also implies that > representational > > is the only possible default, and that there can be no migration from it. > > > > My approach to thinking about this is guided by thinking about > supporting an > > eco-system with 1000s of libraries (hackage), a few dozen of which are > > heavily promoted (the platform), and a small set that are closely tied to > > the compiler (the core). The availability, speed of release, motivation, > and > > even skill of the the developers varies widely over that range. > > > > I also think about the various "stances" of different developers: > > > > End developer: makes use of libraries, but just builds apps > > Internal developer: makes libraries for internal use in a project > > Casual library writer: makes libraries, primarily for their own needs, > but > > distributed on hackage > > Popular library writer: actively maintains libraries which are widely > used > > Core library writer: maintainer of a core package that stays in lock step > > with the compiler > > > > Then, I think about, for each of these, what is the effect on a new > feature > > on them, their existing code, and future code? Does it affect them only > if > > they are using the feature? If they aren't using the feature? For library > > writers, how does the feature affect clients? If a client wants to use a > > feature, under what conditions does the library need to do something? > This > > last issue of the "transitivity" the feature is often the biggest > concern. > > > > Given that... onto type roles: > > > > The default of representational is the only option, because a default of > > nominal would require far too many developers to have to update their > code. > > I don't believe that we can ever migrate to nominal as default. > > > > The feature implies that any abstract data type that uses a type > parameter > > in certain ways needs annotate to get the full safety afforded now > afforded. > > However, without annotation, the data type is still no worse off than it > was > > before (there is added safety, but not perhaps relevant to the stand > point > > of the library writer). Further, this (pre-existing) non-safety isn't > likely > > a huge concern. Making sure the docs take the tone that most developers > need > > to nothing, and when developers need to be concerned seems like an > important > > way to ensure the right outcome. > > > > A key question here is transitivity: Is it possible for module A to not > > annotate a type, and then have module B b> > _______________________________________________ > > Libraries mailing list > > Libraries(a)haskell.org <javascript:;> > > http://www.haskell.org/mailman/listinfo/libraries > > > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org <javascript:;> > http://www.haskell.org/mailman/listinfo/libraries >

1 0

RE: [commit: ghc] master: Convert haddock into a proper submodule (re #8545) (34b0721)
by Simon Peyton Jones 26 Mar '14

26 Mar '14

Do us naïve users need to change our workflow with these submodule changes? Thanks Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf Of | git(a)git.haskell.org | Sent: 23 March 2014 09:50 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: Convert haddock into a proper submodule | (re #8545) (34b0721) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : master | Link : | http://ghc.haskell.org/trac/ghc/changeset/34b072177b687c8fcc24f87293beae0 | 752e82d32/ghc | | >--------------------------------------------------------------- | | commit 34b072177b687c8fcc24f87293beae0752e82d32 | Author: Herbert Valerio Riedel <hvr(a)gnu.org> | Date: Thu Mar 20 09:20:06 2014 +0100 | | Convert haddock into a proper submodule (re #8545) | | This should help contribute content to | | | https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules | | Signed-off-by: Herbert Valerio Riedel <hvr(a)gnu.org> | | | >--------------------------------------------------------------- | | 34b072177b687c8fcc24f87293beae0752e82d32 | .gitignore | 1 - | .gitmodules | 3 +++ | packages | 2 +- | utils/haddock | 1 + | 4 files changed, 5 insertions(+), 2 deletions(-) | | diff --git a/.gitignore b/.gitignore | index 93feea3..e60382b 100644 | --- a/.gitignore | +++ b/.gitignore | @@ -71,7 +71,6 @@ _darcs/ | /libraries/unix/ | /libraries/utf8-string/ | /nofib/ | -/utils/haddock/ | /utils/hsc2hs/ | | # ---------------------------------------------------------------------- | ------- | diff --git a/.gitmodules b/.gitmodules | index d83bfd0..99893a4 100644 | --- a/.gitmodules | +++ b/.gitmodules | @@ -54,3 +54,6 @@ | path = libraries/random | url = ../packages/random.git | ignore = untracked | +[submodule "utils/haddock"] | + path = utils/haddock | + url = ../haddock.git | diff --git a/packages b/packages | index 616dfc1..2683c99 100644 | --- a/packages | +++ b/packages | @@ -47,7 +47,7 @@ | ghc-tarballs windows ghc-tarballs.git | - | libffi-tarballs - libffi-tarballs.git | - | utils/hsc2hs - hsc2hs.git | - | -utils/haddock - haddock.git | - | +utils/haddock - - | - | libraries/array - packages/array.git | - | libraries/base - packages/base.git | - | libraries/binary - - | https://github.com/kolmodin/binary.git | diff --git a/utils/haddock b/utils/haddock | new file mode 160000 | index 0000000..725faca | --- /dev/null | +++ b/utils/haddock | @@ -0,0 +1 @@ | +Subproject commit 725faca5ee670f80359321adc112408880e9c073 | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits

3 4

Re: We need to add role annotations for 7.8
by Herbert Valerio Riedel 25 Mar '14

25 Mar '14

On 2014-03-25 at 09:28:57 +0100, Andreas Abel wrote: [...] > You might wanna pull the break before the release. Fwiw, reverting the new syntax at this point also has an effect on already officially released libraries such as http://hackage.haskell.org/package/containers-0.5.5.1 which started using the new non-pragma annotation[1]; so this would require new hackage uploads (and maybe hackage-deprecations)... just saying... [1]: http://hdiff.luite.com/cgit/containers/commit?id=0.5.5.0

1 0