RE: RFC: Dropping Windows XP support
I don't think we should worry about windows server 2003. Unless I'm mistaken the support Microsoft still provides is mostly maintenance. The older version of GHC won't suddenly stop working on 2003, as such all programs will continue to run just fine. From a development standpoint removing = NT 5 support from would be very beneficial. For those on the older platforms, they can use the older GHCs, which I think is the policy most companies have taken w.r.t. Xp/2003. Regards, TamarFrom: Gershom B Sent: 08/11/2014 01:20 To: Austin Seipp; ghc-devs@haskell.org; glasgow-haskell-us...@haskell.org Subject: Re: RFC: Dropping Windows XP support One concern here is that even with XP falling out of support, Windows Server 2003 remains supported through July 2015, and so we should give it a little chunk of time after that falls out of support from Microsoft before we stop supporting that. I think the limitations in Server 2003 are roughly the same as XP. http://www.microsoft.com/en-us/server-cloud/products/windows-server-2003/ However, the next Windows Server (2008) should share all Vista features. Cheers, Gershom On November 7, 2014 at 1:16:39 PM, Austin Seipp (aus...@well-typed.com) wrote: Hi all, This is a quick discussion about the current system requirements for Windows builds. Spurred by a recent[1] LLVM discussion, I'd like to raise the question of dropping support for Windows XP, and bumping the minimum required version to Windows Vista or even Windows 7. For one, Microsoft doesn't support XP anymore, so most people are moving off it anyway. 'Soon' even XP Embedded will be obsoleted. But second, Vista and beyond introduced useful new APIs we could use. I was digging through the LLVM thread and two came out to me: 1) We could switch to using slim reader/writer locks, which in some workloads may work out better than critical sections (they'll win on more read-heavy workloads). The downsides is there's no recursive locking but we don't use that anyway (and recursive locks are considered bad by many anyway[2]). 2) We could probably use an actual condition variables API that was introduced with Vista. Currently we use a giant EVENT object to emulate the API, which could be replaced with the real deal. Both of these could be nice wins for simplicity and performance I think. I know there are some corporate users out there who this may impact, and users as well. I'd like to know what people think. Particularly what version we should standardize on. FWIW, I don't plan on changing any of this until the 7.12 release at least. [1] http://article.gmane.org/gmane.comp.compilers.llvm.devel/78419 [2] http://www.zaval.org/resources/library/butenhof1.html -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ Glasgow-haskell-users mailing list glasgow-haskell-us...@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
let/app invariant violated by code generated with mkCoreApp
Hi, I'm trying to attach (f Void#) as a compulsory unfolding to an Id. Here's what I tried originally: let unfolding = mkCoreApp (Var worker_id) (Var voidPrimId) wrapper_id' = setIdUnfolding wrapper_id $ mkCompulsoryUnfolding unfolding However, when I try to use wrapper_id' in the desugarer, the Core linter looks at me strange. This is the original Core: f :: Int [LclIdX, Str=DmdType] f = break1() GHC.Types.I# Main.$WPAT and this is the error message ($WPAT is the wrapper_id', PAT is the worker_id in this example) no location info: Warning: In the expression: I# (PAT void#) This argument does not satisfy the let/app invariant: PAT void# Now, I thought I'd make sure mkCoreApp generated correct Core by writing it out by hand: let unfolding = Case (Var voidPrimId) voidArgId pat_ty [(DEFAULT,[],App (Var worker_id) (Var voidArgId))] however, bizarrely, this *still* results in *the same* error message, as if something was transforming it back to a straight App. Anyone have any hints what I'm doing wrong here? Bye, Gergo -- .--= ULLA! =-. \ http://gergo.erdi.hu \ `---= ge...@erdi.hu =---' You are in a twisty maze of little install diskettes. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Concrete syntax for pattern synonym type signatures
Just a small note about parsing: On Tue, 4 Nov 2014, Simon Peyton Jones wrote: The more I think about this, the more I think we'll just have to bite the bullet and adapt the syntax for constraints in pattern types, to distinguish the match-required and match-provided parts. Suppose we let pattern signatures look like this: pattern P :: forall tvs. (match-provided ; match-required) = tau The ; match-required part is optional, and the match-provided part might be empty. So P1 and P2 would look like this: pattern P1 :: forall a. (; Num a) = b - (a,b) pattern P2 :: forall a. (; Num a, Ord a) = a - a Because the match-required part is optional (and relatively rare) the common case looks just like an ordinary data constructor. One thing worth noting is that implementing a parser for this would be far from straightforward, because currently contexts are parsed as types and then fixed up into contexts: -- We parse a context as a btype so that we don't get reduce/reduce -- errors in ctype. The basic problem is that -- (Eq a, Ord a) -- looks so much like a tuple type. We can't tell until we find the = So we would need to add a way of parsing (T1, T2, ..., Tn; U1, U2, ..., Um) into a type, which would then require rejecting everywhere else where we really do mean a type... Sounds painful. Also painful: rewriting the whole context parsing code :/ Richard's suggestion: pattern type forall a. Num a = P :: forall c. (Eq a, Ord Bool, Show c) = c - Bool - T a Bool has the nice property (unlike the current horrible syntax) that the foralls close left-to-right; also, it is very easy to parse :) I'm hoping to see some more suggestions or general comments! Bye, Gergo ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Fw: Long term support - in general and Windows XP specifically
Hi, I am combining the two topics because the issues are both support-related. First, long term support (LTS) is an important goal in making GHC/Haskell a viable production platform. I would argue that providing it is a necessary condition to encourage more adoption of Haskell by plain users (as opposed to those willing to take more risks). This includes both individuals and organizations. I believe this makes LTS a high priority for the community. LTS requires support of both GHC and stable libraries. Any plan for LTS must incorporate a plan for identifying libraries to keep supporting for the same period. This must be part of the effort. FP Complete's Stackage is one approach. Practically, each LTS version requires significant maintainer resources. Therefore, there is a tension between how many versions to support, how long to support them, and how much demand there will be for new features. The developers need to get a sense of how much value the plain user will get from a new release versus bug fixes and backports to an LTS release. As a thought experiment (and perhaps a survey of users), how many users are content with GHC 7.4, 7.6 and 7.8, or even earlier releases? Will they clamor for the new features in 7.10, or is this more aimed at those who are experimenting or are willing to take greater risk? What is the current demographic of users/GHC release usage? Based on the results of this study, we'll have a better idea of what release to make the first LTS one. I would suggest starting with a prior release based on what is being used now. For example, find out how many users are using 7.4 and ask what difficulties they would have in adopting 7.6. Try to get a sense of what the first LTS release should be, recognizing that you won't get unanimous agreement. I am an interested observer, not an active developer, so take my comments with this in mind. I wonder if the release of 7.10 is being rushed. Perhaps once a year releases are too frequent for everyone except the bleeding edge, who may be satisfied with snapshots. Maybe a reallocation of developer effort should be considered. This question deserves to be considered even if it is ultimately discarded. The issue of Windows XP support should be considered using a similar approach. If an LTS release is created with Windows XP support, this should satisfy XP users for a period of time. It could then be discussed when XP support would no longer be part of a later version. I don't know what API differences there are between XP and Vista or Window 7 that impact GHC. Do the newer APIs provide a significant benefit that justifies dropping XP support? Could newer features be used only where essential, so degraded XP support can be maintained longer? I hope my perspective is of value to the developers. Regards, Howard Northridge, CA, USA - Original Message - From: Austin Seipp aus...@well-typed.com To: ghc-devs@haskell.org ghc-devs@haskell.org Cc: Sent: Friday, November 7, 2014 2:07 PM Subject: GHC Weekly News - 2014/11/07 [Excerpt] - Austin also opened a discussion about a possible LTS branch for GHC, spawned off from a suggestion by John Lato a few weeks email. This discussion has been brought up several times before this, but for the most part has fizzled out a bit. But maybe with a different focus - on a separate branch with a team of maintainers - we can hash out a plan of action, and just give it a whirl. https://www.haskell.org/pipermail/ghc-devs/2014-November/007207.html - Austin Seipp brought up a question about Windows support: can we officially drop support for XP, now that Microsoft has done the same? And what minimum version requirements should we endorse? Vista or Windows 7 would give improvements due to API improvements, with Windows 7 offering even more. If you're a GHC on Windows user, please let us know! https://www.haskell.org/pipermail/ghc-devs/2014-November/007199.html ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Wiki: special namespace for proposals?
On 15/10/14 09:37, Simon Peyton Jones wrote: I think that would be a fine idea, but it's always hard - pages change their status (a proposal becomes part of GHC) - a page may belong in multiple places - people keep URLs in bookmarks, and they are linked from other pages in Trac so moving pages is painful. The last is significant. Do we leave this page has moved stub pages (i.e. still cluttering the TitleIndex). Or do we move them, and live with dead links. I'm very un-keen on dead links in Trac itself. Maybe there is some way to rewrite all of those, at least? You can leave indirections in place in Trac, like this: [[redirect(wiki:Building/Preparation/Windows)]] I've done this a few times when I moved pages to better organise things. I agree that it does leave some clutter in TitleIndex, that's unfortunate, but I think it's worth it to have good organisation. Cheers, Simon I don't have a strong opinion here Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of | Yuras Shumovich | Sent: 14 October 2014 23:13 | To: ghc-devs@haskell.org Devs | Subject: Wiki: special namespace for proposals? | | | Hello, | | Would it be better to organize proposals under one namespace? Right | now they belongs to root namespace, so title index ( | https://ghc.haskell.org/trac/ghc/wiki/TitleIndex ) is hard to use. | | I was going to start new page describing language extension, but I | don't want do increase entropy even more. What about creating special | namespace, e.g. Proposals? Probably makes sense to divide if | farther? | | Thanks, | Yuras | | ___ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Question about `validate` workflow
Hello, I was wondering how do other devs `validate` their tree? In particular, I just merged a whole bunch of stuff and am validating things. However, every time something goes wrong (e.g., unused import warning), the whole process starts from the beginning, which is quite time consuming. I am using CPUS=4 ./validate --fast Can I do something, to validate continue, at least until I get a basic validate to pass? I don't mind redoing everything one final time to make sure things are OK, it is just that it seems wasteful while I am fixing things. -Iavor ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Question about `validate` workflow
I was wondering how do other devs `validate` their tree? In particular, I just merged a whole bunch of stuff and am validating things. However, every time something goes wrong (e.g., unused import warning), the whole process starts from the beginning, which is quite time consuming. $ ./validate --help ... --no-cleandon't make clean first, just carry on from a previous interrupted validation run ... I don't know if it works! ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Fw: Long term support - in general and Windows XP specifically
On 11/08/2014 07:32 PM, Howard B. Golden wrote: Hi, I am combining the two topics because the issues are both support-related. First, long term support (LTS) is an important goal in making GHC/Haskell a viable production platform. I would argue that providing it is a necessary condition to encourage more adoption of Haskell by plain users (as opposed to those willing to take more risks). This includes both individuals and organizations. I believe this makes LTS a high priority for the community. LTS requires support of both GHC and stable libraries. Any plan for LTS must incorporate a plan for identifying libraries to keep supporting for the same period. This must be part of the effort. FP Complete's Stackage is one approach. Practically, each LTS version requires significant maintainer resources. Therefore, there is a tension between how many versions to support, how long to support them, and how much demand there will be for new features. The developers need to get a sense of how much value the plain user will get from a new release versus bug fixes and backports to an LTS release. As a thought experiment (and perhaps a survey of users), how many users are content with GHC 7.4, 7.6 and 7.8, or even earlier releases? Will they clamor for the new features in 7.10, or is this more aimed at those who are experimenting or are willing to take greater risk? What is the current demographic of users/GHC release usage? Based on the results of this study, we'll have a better idea of what release to make the first LTS one. I would suggest starting with a prior release based on what is being used now. For example, find out how many users are using 7.4 and ask what difficulties they would have in adopting 7.6. Try to get a sense of what the first LTS release should be, recognizing that you won't get unanimous agreement. I am an interested observer, not an active developer, so take my comments with this in mind. I wonder if the release of 7.10 is being rushed. Perhaps once a year releases are too frequent for everyone except the bleeding edge, who may be satisfied with snapshots. Maybe a reallocation of developer effort should be considered. This question deserves to be considered even if it is ultimately discarded. If organisations care then they should voice their thoughts *and* provide some developer effort to make the backports. Delaying new releases and pulling off volunteers to do soul-crushing fix backporting because it might, just might, make it easier for some business out there to achieve something is silly. No one wants to put their free time into porting stuff years back especially if it might not even matter. The issue of Windows XP support should be considered using a similar approach. If an LTS release is created with Windows XP support, this should satisfy XP users for a period of time. It could then be discussed when XP support would no longer be part of a later version. I don't know what API differences there are between XP and Vista or Window 7 that impact GHC. Do the newer APIs provide a significant benefit that justifies dropping XP support? Could newer features be used only where essential, so degraded XP support can be maintained longer? XP came out in 2001. There's LTS and then there's 13 year old OS that's after EOL from its own developer. I hope my perspective is of value to the developers. Regards, Howard Northridge, CA, USA - Original Message - From: Austin Seipp aus...@well-typed.com To: ghc-devs@haskell.org ghc-devs@haskell.org Cc: Sent: Friday, November 7, 2014 2:07 PM Subject: GHC Weekly News - 2014/11/07 [Excerpt] - Austin also opened a discussion about a possible LTS branch for GHC, spawned off from a suggestion by John Lato a few weeks email. This discussion has been brought up several times before this, but for the most part has fizzled out a bit. But maybe with a different focus - on a separate branch with a team of maintainers - we can hash out a plan of action, and just give it a whirl. https://www.haskell.org/pipermail/ghc-devs/2014-November/007207.html - Austin Seipp brought up a question about Windows support: can we officially drop support for XP, now that Microsoft has done the same? And what minimum version requirements should we endorse? Vista or Windows 7 would give improvements due to API improvements, with Windows 7 offering even more. If you're a GHC on Windows user, please let us know! https://www.haskell.org/pipermail/ghc-devs/2014-November/007199.html ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: 7.10 STABLE freeze date
Hello, I've submitted a patch to finish the already-merged (but incomplete) ARM64 support that adds support for modern iOS devices https://ghc.haskell.org/trac/ghc/ticket/7942 Best Luke (I've also submitted a patch to LLVM to add an ARM64 GHC calling convention that is in review) On Fri, Nov 7, 2014 at 1:35 PM Austin Seipp aus...@well-typed.com wrote: Hi all, After some deliberation, we've decided that the STABLE freeze for 7.10 will happen in approximately two weeks, on November 21st. We're hoping to stick to this date closely, but do read below. This is perhaps a short time to freeze, but right now, we've only got a couple things we're planning on focusing on for the next few weeks. And these are really the major things we're waiting for. See below: - https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.1 These are just: - D155, LLVM 3.5 compatibility, - D396 and D169, DWARF/source code note work. These are mostly in me and Simon's court to do another review round, but I think will be OK to get them in on time. - D168, Partial type signatures. The ball is in Simon's court on this one, but he's had several good rounds of discussion with Thomas etc from what I understand. Based on our discussions earlier this week, I think these all will make it just in time for the freeze. Nota bene: if there is *any* delay, it will be for these, as we picked them as the highest priority in our own views. It is unlikely we will delay any so people can sneak in a few other things. So, if you want something of yours in, you better get me, Simon Simon, Herbert, etc's attention pronto! That way we'll have time to get it in first. To make things easier, we'll also be pushing the lhs-hs conversion pretty soon so cherry picking/merges are easier, and do some other cleanups. And outside of that, we've still been having a healthy flow of bug fixes falling into the tree, which is great. So if you're just bugfixing, please keep doing so - we'll be pulling bugfixes into the tree continuously. We will also be pulling in submodule/library updates continuously, like we did for the 7.8 branch. Let me know if you have questions, objections, or really really really want something - but I won't be as nice as last time I'm afraid. ;) -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Question about `validate` workflow
It does work, and it's very useful. Edward Excerpts from Thomas Miedema's message of 2014-11-08 14:35:27 -0800: I was wondering how do other devs `validate` their tree? In particular, I just merged a whole bunch of stuff and am validating things. However, every time something goes wrong (e.g., unused import warning), the whole process starts from the beginning, which is quite time consuming. $ ./validate --help ... --no-cleandon't make clean first, just carry on from a previous interrupted validation run ... I don't know if it works! ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Concrete syntax for pattern synonym type signatures
On Nov 8, 2014, at 11:23 AM, Dr. ERDI Gergo ge...@erdi.hu wrote: So we would need to add a way of parsing (T1, T2, ..., Tn; U1, U2, ..., Um) into a type, which would then require rejecting everywhere else where we really do mean a type... Sounds painful. Also painful: rewriting the whole context parsing code :/ I actually think this wouldn't be all that hard. The same parse-as-wrong-AST-node-and-then-fix-it-up-later trick happens in plenty of places, patterns (parsed as expressions) being one of the biggest. Harder than my proposal, probably, but I don't think it's terrible. Richard's suggestion: pattern type forall a. Num a = P :: forall c. (Eq a, Ord Bool, Show c) = c - Bool - T a Bool has the nice property (unlike the current horrible syntax) that the foralls close left-to-right; also, it is very easy to parse :) One slight infelicity of my syntax is that the `P` is buried. I should also note that I intended the `forall`s to be optional. The universally-quantified variables would be those that appear in the result type. (I conjecture without proof that the free variables of the required constraints must be a subset of the free variables of the result type. I further conjecture that said proof is easy, but the neurons capable of producing said proof have the night off.) The existentially-quantified variables are the other ones. Given that the `forall`s are optional and that required constraints are likely rare (I agree there), then the P does not get buried often. My syntax has the felicity that, like Simon's, if we make a pattern synonym for a GADT constructor, without any funny business, the pattern type is the same as the GADT type. It also supports a reading that says, for the example P, As long as we have Num a, then P has the type (...), which is a correct reading of the type. Richard ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Question about `validate` workflow
I've stopped validating locally, allowing Travis to do it for me. If you use a `wip/...` branch and push to the main GHC repo, you can find build reports at travis-ci.org/ghc/ghc. Or, I'm sure if you clue Travis in, this can also work if you push to your own GitHub fork of GHC. Admittedly, this is a bad workflow if you're expecting a bunch of extraneous-import failures (and such) during validation, but I just wanted to make sure you knew of this option. Richard On Nov 8, 2014, at 7:50 PM, Edward Z. Yang ezy...@mit.edu wrote: It does work, and it's very useful. Edward Excerpts from Thomas Miedema's message of 2014-11-08 14:35:27 -0800: I was wondering how do other devs `validate` their tree? In particular, I just merged a whole bunch of stuff and am validating things. However, every time something goes wrong (e.g., unused import warning), the whole process starts from the beginning, which is quite time consuming. $ ./validate --help ... --no-cleandon't make clean first, just carry on from a previous interrupted validation run ... I don't know if it works! ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Concrete syntax for pattern synonym type signatures
On Sat, 8 Nov 2014, Richard Eisenberg wrote: On Nov 8, 2014, at 11:23 AM, Dr. ERDI Gergo ge...@erdi.hu wrote: So we would need to add a way of parsing (T1, T2, ..., Tn; U1, U2, ..., Um) into a type, which would then require rejecting everywhere else where we really do mean a type... Sounds painful. Also painful: rewriting the whole context parsing code :/ I actually think this wouldn't be all that hard. The same parse-as-wrong-AST-node-and-then-fix-it-up-later trick happens in plenty of places, patterns (parsed as expressions) being one of the biggest. Harder than my proposal, probably, but I don't think it's terrible. Right, but the issue in this case is if we add this artifical constructor to HsType just so we can fix it up into a pair of contexts, this constructor would permeate everything else that has to do with HsTypes; if nothing else, it'd need a `panic foo: HsContextPair` branch for all type-related renamer/typechecker functions. Unless I'm missing some shortcut. I hope I do! Bye, Gergo ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Concrete syntax for pattern synonym type signatures
On Nov 8, 2014, at 10:42 PM, Dr. ERDI Gergo ge...@erdi.hu wrote: Right, but the issue in this case is if we add this artifical constructor to HsType just so we can fix it up into a pair of contexts, this constructor would permeate everything else that has to do with HsTypes; if nothing else, it'd need a `panic foo: HsContextPair` branch for all type-related renamer/typechecker functions. Unless I'm missing some shortcut. I hope I do! No, you're right that you would have to do this, but this turns out to be the least of your worries -- takes 5 minutes. :) Now, if I could only predict what would be the *most* of your worries, I'd be a much more efficient programmer! Richard ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Concrete syntax for pattern synonym type signatures
On Sat, 8 Nov 2014, Richard Eisenberg wrote: I should also note that I intended the `forall`s to be optional. Of course, the forall binders are optional in all proposals. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Concrete syntax for pattern synonym type signatures
On 11/04/2014 05:32 AM, Simon Peyton Jones wrote: The ; match-required part is optional, and the match-provided part might be empty. So P1 and P2 would look like this: pattern P1 :: forall a. (; Num a) = b - (a,b) pattern P2 :: forall a. (; Num a, Ord a) = a - a How about marking the match-provided parts with a keyword, as so: pattern P2 :: (match_required Num a, match_required Ord a) = a - a Except with a better keyword. if might do in a pinch: pattern P2 :: forall a. (if Num a, if Ord a) = a - a or pattern needed (pattern being a keyword) or pattern forall pattern P2 :: (pattern needed Num a, pattern needed Ord a) = a - a ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Fw: Long term support - in general and Windows XP specifically
On 2014-11-08 at 20:32:17 +0100, Howard B. Golden wrote: [...] I am an interested observer, not an active developer, so take my comments with this in mind. I wonder if the release of 7.10 is being rushed. Perhaps once a year releases are too frequent for everyone except the bleeding edge, who may be satisfied with snapshots. Maybe a reallocation of developer effort should be considered. This question deserves to be considered even if it is ultimately discarded. Fyi, last year there was already a discussion sub-thread debating a change of GHC's yearly major release cycle over at http://thread.gmane.org/gmane.comp.lang.haskell.glasgow.user/23425/focus=23451 IIRC, the conclusion was basically that a yearly cycle is a good compromise balancing all needs/wishes involved. IMO, since GHC gains so many new features/improvements every year already, releasing less often would, for one, increase the amount of new (potentially non-backward compatible changes) features contained in a release, therefore increasing the work involved to update old code-bases to a new GHC release[1], while at the same time give less opportunity to get short release-feedback cycles (as Hackage developers probably only take serious proper stable GHC releases (candidates), rather than work-in-progress snapshots that are fast moving targets, potentially exhibiting all sorts of transient bugs). IOW, what I'm basically saying is that I'm a proponent of http://en.wikipedia.org/wiki/Release_early,_release_often [1]: An *extreme* example of what can happen if you accumulate too many changes into a new compiler/language release is the Python3 situation, where it took ages for code-bases to get updated/ported from Python2 to Python3 (and it's still ongoing), as the upgrade path was too steep, while Python3 development was even slowed down for a few years by a self-imposed Python Language Moratorium to let Python3's adoption catch up. Cheers, hvr ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Concrete syntax for pattern synonym type signatures
On Tue, 4 Nov 2014, Simon Peyton Jones wrote: pattern P :: forall tvs. (match-provided ; match-required) = tau The ; match-required part is optional, and the match-provided part might be empty. So P1 and P2 would look like this: pattern P1 :: forall a. (; Num a) = b - (a,b) pattern P2 :: forall a. (; Num a, Ord a) = a - a Doesn't the ';' look a bit like something that could be incidentially introduced by some layout-aware syntax rule? Wouldn't, e.g., '|' be more explicit as a separator? example: pattern P :: forall tvs. (Eq b | Num a, Eq a) = b - T a ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
