On 19/05/17 07:12 PM, Francesco Ariis wrote:
I thought about this. But I fear that this will require a language extension or flag, and then the developers (quite rightly) say that it does not pull its weight of supporting both variants, and it gets lost. But maybe I should give it a shot if they accept it. Indeed this strikes me as a not a good extension to have: every extension further fragments the ecosystem and is yet another thing to care about if you are reading someone else's code, etc. - the cost probably outweights
On Fri, May 19, 2017 at 06:32:30PM -0400, Joachim Breitner wrote: the benefit on this one.
But it seems a good proposal for H2020, as (if it is accepted), the costs linked with an extension/flag (added complexity, fragmentation of the community) aren't there.
The "extensions before report modification" is a solid rule, maybe the committee wants to add an exception for proposals which cannot realistically be "packaged" (and achieve widespread use) into extensions?
I feel it's rather ironic that there exists a class of proposals that are considered acceptable for Haskell' but too radical for GHC, considering that the stands are usually completely opposite. The obvious way out of this conundrum is to communicate with GHC. If the Haskell' committee gives a proposal some sort of conditional acceptance status, that should count for something with the GHC HQ. After all, they'd presumably have to implement it once it's officially a part of the next standard, so implementing it sooner as a proposal is not that much more to ask.