From mail at joachim-breitner.de Sat Oct 7 18:26:02 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sat, 07 Oct 2017 14:26:02 -0400 Subject: [ghc-steering-committee] Proposal: Type Fixity (#65), Consensus: accept, own language extension? In-Reply-To: <1505924631.5913.14.camel@joachim-breitner.de> References: <1503857788.4643.2.camel@joachim-breitner.de> <1505924631.5913.14.camel@joachim-breitner.de> Message-ID: <1507400762.25530.5.camel@joachim-breitner.de> Hi Committee, the discussion has ebbed down again. I observe that a clear majority is in favor. I don’t think there is a need for a formal vote, so I will proceed with this decision. Simon M brought up the next issue: Shall we require a separate language extension for this, or can it go under the hood of `ExplicitNamespaces`? So far Simon M expressed a strong preference for the former, while I am inclined to prefer the latter, and would like to hear a few more opinions on this detail (which certainly would set precedence for future decisions). Richard brought up the idea of versioned language extensions; that idea can certainly be investigated, but better independently. We have to deal with this proposal with the tools we have. Greetings, Joachim Am Mittwoch, den 20.09.2017, 12:23 -0400 schrieb Joachim Breitner: > Hi, > > the type fixity proposal > (https://github.com/ghc-proposals/ghc-proposals/pull/65) > was met with mixed reactions. > > * I recommended rejection and Manuel strongly agrees with me. > * SPJ does not have strong opinions either way. > * Richard is in favor, and Iavor agrees. > > > Our process says “If consensus is elusive, then we vote, with the > Simons retaining veto power.” It looks like this might be such a case. > Should we go ahead and vote, or is more discussion likely to sway some > of us? > > (I guess I can be swayed towards acceptance, especially if this > proposal re-uses existing syntactic idioms from export lists with > ExplicitNamespaces on.) > > Greetings, > Joachim > > > > Am Sonntag, den 27.08.2017, 20:16 +0200 schrieb Joachim Breitner: > > Dear Committee, > > > > Ryan Scott’s proposal to allow fixity declaration to explicitly target > > values or types has been brought before us: > > https://github.com/RyanGlScott/ghc-proposals/blob/type-infix/0000-type-infix.rst > > https://github.com/ghc-proposals/ghc-proposals/pull/65 > > > > I (the secretary) nominates myself as the shepherd, so I can right away > > continue giving a recommendation. > > > > I propose to reject this proposal. The main reasons are: > > * it is not clear if there is a real use case for this. Has anyone > > ever complained about the status quo? > > The proposal does not motivate the need for a change well enough. > > (There is a related bug in TH, but that bug can probably simply be > > fixed.) > > * The status quo can be sold as a feature, rather than a short-coming. > > Namely that an operator has a fixed fixity, no matter what namespace > > it lives in. > > This matches morally what other languages do: In Gallina, fixity > > is assigned to names independent of their definition, AFAIK. > > * There is a non-trivial implementation and education overhead, a > > weight that is not pulled by the gains. > > > > If we’d design Haskell from scratch, my verdict might possibly be > > different (but maybe we wouldn’t even allow types and values to share > > names then…) > > > > > > Please contradict me or indicate consensus by staying silent. > > > > > > Greetings, > > Joachim > > > > _______________________________________________ > > ghc-steering-committee mailing list > > ghc-steering-committee at haskell.org > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From iavor.diatchki at gmail.com Tue Oct 10 02:54:29 2017 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Tue, 10 Oct 2017 02:54:29 +0000 Subject: [ghc-steering-committee] Proposal: Type Fixity (#65), Consensus: accept, own language extension? In-Reply-To: References: <1503857788.4643.2.camel@joachim-breitner.de> <1505924631.5913.14.camel@joachim-breitner.de> <1507400762.25530.5.camel@joachim-breitner.de> Message-ID: Hello, my preference would be to add this to one of the existing extensions (either "explicit namespaces", or "type level operators"). Iavor On Sat, Oct 7, 2017 at 11:26 AM Joachim Breitner wrote: > Hi Committee, > > the discussion has ebbed down again. I observe that a clear majority is > in favor. I don’t think there is a need for a formal vote, so I will > proceed with this decision. > > Simon M brought up the next issue: Shall we require a separate language > extension for this, or can it go under the hood of > `ExplicitNamespaces`? > > So far Simon M expressed a strong preference for the former, while I am > inclined to prefer the latter, and would like to hear a few more > opinions on this detail (which certainly would set precedence for > future decisions). > > Richard brought up the idea of versioned language extensions; that idea > can certainly be investigated, but better independently. We have to > deal with this proposal with the tools we have. > > Greetings, > Joachim > > > Am Mittwoch, den 20.09.2017, 12:23 -0400 schrieb Joachim Breitner: > > Hi, > > > > the type fixity proposal > > (https://github.com/ghc-proposals/ghc-proposals/pull/65) > > was met with mixed reactions. > > > > * I recommended rejection and Manuel strongly agrees with me. > > * SPJ does not have strong opinions either way. > > * Richard is in favor, and Iavor agrees. > > > > > > Our process says “If consensus is elusive, then we vote, with the > > Simons retaining veto power.” It looks like this might be such a case. > > Should we go ahead and vote, or is more discussion likely to sway some > > of us? > > > > (I guess I can be swayed towards acceptance, especially if this > > proposal re-uses existing syntactic idioms from export lists with > > ExplicitNamespaces on.) > > > > Greetings, > > Joachim > > > > > > > > Am Sonntag, den 27.08.2017, 20:16 +0200 schrieb Joachim Breitner: > > > Dear Committee, > > > > > > Ryan Scott’s proposal to allow fixity declaration to explicitly target > > > values or types has been brought before us: > > > > https://github.com/RyanGlScott/ghc-proposals/blob/type-infix/0000-type-infix.rst > > > https://github.com/ghc-proposals/ghc-proposals/pull/65 > > > > > > I (the secretary) nominates myself as the shepherd, so I can right away > > > continue giving a recommendation. > > > > > > I propose to reject this proposal. The main reasons are: > > > * it is not clear if there is a real use case for this. Has anyone > > > ever complained about the status quo? > > > The proposal does not motivate the need for a change well enough. > > > (There is a related bug in TH, but that bug can probably simply be > > > fixed.) > > > * The status quo can be sold as a feature, rather than a short-coming. > > > Namely that an operator has a fixed fixity, no matter what namespace > > > it lives in. > > > This matches morally what other languages do: In Gallina, fixity > > > is assigned to names independent of their definition, AFAIK. > > > * There is a non-trivial implementation and education overhead, a > > > weight that is not pulled by the gains. > > > > > > If we’d design Haskell from scratch, my verdict might possibly be > > > different (but maybe we wouldn’t even allow types and values to share > > > names then…) > > > > > > > > > Please contradict me or indicate consensus by staying silent. > > > > > > > > > Greetings, > > > Joachim > > > > > > _______________________________________________ > > > ghc-steering-committee mailing list > > > ghc-steering-committee at haskell.org > > > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > > > -- > > Joachim Breitner > > mail at joachim-breitner.de > > http://www.joachim-breitner.de/ > > > > _______________________________________________ > > ghc-steering-committee mailing list > > ghc-steering-committee at haskell.org > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Tue Oct 10 03:38:48 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 09 Oct 2017 23:38:48 -0400 Subject: [ghc-steering-committee] Status Message-ID: <1507606728.345.6.camel@joachim-breitner.de> Hi, already a month since the last status! Since the last status update, one proposals was accepted. I have also moved NOUNPACK on function arguments to status “dormant”, until the proposal is updated to reflect recent discussion. Open at the moment are: Lazy unboxed tuples https://github.com/ghc-proposals/ghc-proposals/pull/35 Shepherd: Ryan Newton Status: Still waiting for Ryan to make a recommendation. Mutable constructor fields https://github.com/ghc-proposals/ghc-proposals/pull/8 Shepherd: Ryan Newton Status: Waiting for Ryan to make a recommendation. Or Patterns https://github.com/ghc-proposals/ghc-proposals/pull/43 Shepherd: Manuel Chakravarty Status: Waiting for Manuel to make a recommendation. Type fixity https://github.com/ghc-proposals/ghc-proposals/pull/65 Shepherd: Joachim Breitner Status: Not consensus, but majority for “accept”. Current discussion revolves around the question: Can this be included in ExplicitNamespaces, or does it require a separate language extension. The proposer also points out that explicit namespaces would also be useful for various pragmas. Besides these, there are some proposals actively under discussion. You can always check them out at https://github.com/ghc-proposals/ghc-proposals/pulls?q=is%3Aopen+is%3Apr+no%3Alabel Greetings, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From marlowsd at gmail.com Tue Oct 17 07:53:30 2017 From: marlowsd at gmail.com (Simon Marlow) Date: Tue, 17 Oct 2017 08:53:30 +0100 Subject: [ghc-steering-committee] Proposal: Type Fixity (#65), Consensus: accept, own language extension? In-Reply-To: References: <1503857788.4643.2.camel@joachim-breitner.de> <1505924631.5913.14.camel@joachim-breitner.de> <1507400762.25530.5.camel@joachim-breitner.de> Message-ID: The main reason I took a position on the issue of extension flags is to force the question: what should LANGUAGE mean? I think it's important to resolve this, to inform future decisions. Here are some options: 1. LANGUAGE fully specifies the grammar of the source file 2. LANGUAGE fully specifies the grammar and semantics of the source file 3. LANGUAGE tells the compiler what extensions are required, but otherwise provides no guarantees. The source file might not compile with a given version of GHC even if it supports all the extensions listed. In other words, LANGUAGE together with a GHC version range specifies the grammar and semantics of the source file. I think what we have right now is 3, because we change the meaning of extensions from version to version of GHC. There are advantages to 1 and 2: for example, if we had 1, then we could parse all of Hackage with haskell-src-exts (or at least identify the subset of source files that can be parsed via their LANGUAGE pragmas). If we had 2, then we could parse, rename and typecheck all of Hackage using haskell-src-exts, haskel-names, and haskell-type-exts. Perhaps we want to say that we can only *add* syntax to an existing extension, not change or remove it. This is a variant of 3 that requires only a lower bound on the GHC version required, not an upper bound, and it provides some of the benefits of 1 and 2: you just need a sufficiently recent version of haskell-src-exts et. al. Anyway, I mainly wanted to ensure that we're clear about what LANGUAGE means. If we believe the implications of 1 and 2 are too onerous (never changing extensions), so what we want is 3, so be it. Cheers Simon On 10 October 2017 at 03:54, Iavor Diatchki wrote: > > > > Hello, > > my preference would be to add this to one of the existing extensions > (either "explicit namespaces", or "type level operators"). > > Iavor > > > > > > On Sat, Oct 7, 2017 at 11:26 AM Joachim Breitner > wrote: > >> Hi Committee, >> >> the discussion has ebbed down again. I observe that a clear majority is >> in favor. I don’t think there is a need for a formal vote, so I will >> proceed with this decision. >> >> Simon M brought up the next issue: Shall we require a separate language >> extension for this, or can it go under the hood of >> `ExplicitNamespaces`? >> >> So far Simon M expressed a strong preference for the former, while I am >> inclined to prefer the latter, and would like to hear a few more >> opinions on this detail (which certainly would set precedence for >> future decisions). >> >> Richard brought up the idea of versioned language extensions; that idea >> can certainly be investigated, but better independently. We have to >> deal with this proposal with the tools we have. >> >> Greetings, >> Joachim >> >> >> Am Mittwoch, den 20.09.2017, 12:23 -0400 schrieb Joachim Breitner: >> > Hi, >> > >> > the type fixity proposal >> > (https://github.com/ghc-proposals/ghc-proposals/pull/65) >> > was met with mixed reactions. >> > >> > * I recommended rejection and Manuel strongly agrees with me. >> > * SPJ does not have strong opinions either way. >> > * Richard is in favor, and Iavor agrees. >> > >> > >> > Our process says “If consensus is elusive, then we vote, with the >> > Simons retaining veto power.” It looks like this might be such a case. >> > Should we go ahead and vote, or is more discussion likely to sway some >> > of us? >> > >> > (I guess I can be swayed towards acceptance, especially if this >> > proposal re-uses existing syntactic idioms from export lists with >> > ExplicitNamespaces on.) >> > >> > Greetings, >> > Joachim >> > >> > >> > >> > Am Sonntag, den 27.08.2017, 20:16 +0200 schrieb Joachim Breitner: >> > > Dear Committee, >> > > >> > > Ryan Scott’s proposal to allow fixity declaration to explicitly target >> > > values or types has been brought before us: >> > > https://github.com/RyanGlScott/ghc-proposals/ >> blob/type-infix/0000-type-infix.rst >> > > https://github.com/ghc-proposals/ghc-proposals/pull/65 >> > > >> > > I (the secretary) nominates myself as the shepherd, so I can right >> away >> > > continue giving a recommendation. >> > > >> > > I propose to reject this proposal. The main reasons are: >> > > * it is not clear if there is a real use case for this. Has anyone >> > > ever complained about the status quo? >> > > The proposal does not motivate the need for a change well enough. >> > > (There is a related bug in TH, but that bug can probably simply be >> > > fixed.) >> > > * The status quo can be sold as a feature, rather than a >> short-coming. >> > > Namely that an operator has a fixed fixity, no matter what >> namespace >> > > it lives in. >> > > This matches morally what other languages do: In Gallina, fixity >> > > is assigned to names independent of their definition, AFAIK. >> > > * There is a non-trivial implementation and education overhead, a >> > > weight that is not pulled by the gains. >> > > >> > > If we’d design Haskell from scratch, my verdict might possibly be >> > > different (but maybe we wouldn’t even allow types and values to share >> > > names then…) >> > > >> > > >> > > Please contradict me or indicate consensus by staying silent. >> > > >> > > >> > > Greetings, >> > > Joachim >> > > >> > > _______________________________________________ >> > > ghc-steering-committee mailing list >> > > ghc-steering-committee at haskell.org >> > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc- >> steering-committee >> > >> > -- >> > Joachim Breitner >> > mail at joachim-breitner.de >> > http://www.joachim-breitner.de/ >> > >> > _______________________________________________ >> > ghc-steering-committee mailing list >> > ghc-steering-committee at haskell.org >> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc- >> steering-committee >> -- >> Joachim Breitner >> mail at joachim-breitner.de >> http://www.joachim-breitner.de/ >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Oct 17 08:38:34 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 17 Oct 2017 08:38:34 +0000 Subject: [ghc-steering-committee] Proposal: Type Fixity (#65), Consensus: accept, own language extension? In-Reply-To: References: <1503857788.4643.2.camel@joachim-breitner.de> <1505924631.5913.14.camel@joachim-breitner.de> <1507400762.25530.5.camel@joachim-breitner.de> Message-ID: Something like (1) or (2) do seem attractive. But we have, for better or worse, always taken a non-rigid position on back-compat. If it seems the right thing to change a language feature slightly, we have typically done so. For the most part no one notices. Perhaps that’s because a far bigger issue is changes to the base library: those really do affect people. And because of that I don’t think we’ll ever be able to rename and typecheck all of Hackage with any old GHC; there’s always a version range involved. So I think I’m in favour of (3), but with breaches of (1,2) handled with explicit judgement rather than cavalier disregard. Simon From: ghc-steering-committee [mailto:ghc-steering-committee-bounces at haskell.org] On Behalf Of Simon Marlow Sent: 17 October 2017 08:54 To: Iavor Diatchki Cc: ghc-steering-committee at haskell.org Subject: Re: [ghc-steering-committee] Proposal: Type Fixity (#65), Consensus: accept, own language extension? The main reason I took a position on the issue of extension flags is to force the question: what should LANGUAGE mean? I think it's important to resolve this, to inform future decisions. Here are some options: 1. LANGUAGE fully specifies the grammar of the source file 2. LANGUAGE fully specifies the grammar and semantics of the source file 3. LANGUAGE tells the compiler what extensions are required, but otherwise provides no guarantees. The source file might not compile with a given version of GHC even if it supports all the extensions listed. In other words, LANGUAGE together with a GHC version range specifies the grammar and semantics of the source file. I think what we have right now is 3, because we change the meaning of extensions from version to version of GHC. There are advantages to 1 and 2: for example, if we had 1, then we could parse all of Hackage with haskell-src-exts (or at least identify the subset of source files that can be parsed via their LANGUAGE pragmas). If we had 2, then we could parse, rename and typecheck all of Hackage using haskell-src-exts, haskel-names, and haskell-type-exts. Perhaps we want to say that we can only *add* syntax to an existing extension, not change or remove it. This is a variant of 3 that requires only a lower bound on the GHC version required, not an upper bound, and it provides some of the benefits of 1 and 2: you just need a sufficiently recent version of haskell-src-exts et. al. Anyway, I mainly wanted to ensure that we're clear about what LANGUAGE means. If we believe the implications of 1 and 2 are too onerous (never changing extensions), so what we want is 3, so be it. Cheers Simon On 10 October 2017 at 03:54, Iavor Diatchki > wrote: Hello, my preference would be to add this to one of the existing extensions (either "explicit namespaces", or "type level operators"). Iavor On Sat, Oct 7, 2017 at 11:26 AM Joachim Breitner > wrote: Hi Committee, the discussion has ebbed down again. I observe that a clear majority is in favor. I don’t think there is a need for a formal vote, so I will proceed with this decision. Simon M brought up the next issue: Shall we require a separate language extension for this, or can it go under the hood of `ExplicitNamespaces`? So far Simon M expressed a strong preference for the former, while I am inclined to prefer the latter, and would like to hear a few more opinions on this detail (which certainly would set precedence for future decisions). Richard brought up the idea of versioned language extensions; that idea can certainly be investigated, but better independently. We have to deal with this proposal with the tools we have. Greetings, Joachim Am Mittwoch, den 20.09.2017, 12:23 -0400 schrieb Joachim Breitner: > Hi, > > the type fixity proposal > (https://github.com/ghc-proposals/ghc-proposals/pull/65) > was met with mixed reactions. > > * I recommended rejection and Manuel strongly agrees with me. > * SPJ does not have strong opinions either way. > * Richard is in favor, and Iavor agrees. > > > Our process says “If consensus is elusive, then we vote, with the > Simons retaining veto power.” It looks like this might be such a case. > Should we go ahead and vote, or is more discussion likely to sway some > of us? > > (I guess I can be swayed towards acceptance, especially if this > proposal re-uses existing syntactic idioms from export lists with > ExplicitNamespaces on.) > > Greetings, > Joachim > > > > Am Sonntag, den 27.08.2017, 20:16 +0200 schrieb Joachim Breitner: > > Dear Committee, > > > > Ryan Scott’s proposal to allow fixity declaration to explicitly target > > values or types has been brought before us: > > https://github.com/RyanGlScott/ghc-proposals/blob/type-infix/0000-type-infix.rst > > https://github.com/ghc-proposals/ghc-proposals/pull/65 > > > > I (the secretary) nominates myself as the shepherd, so I can right away > > continue giving a recommendation. > > > > I propose to reject this proposal. The main reasons are: > > * it is not clear if there is a real use case for this. Has anyone > > ever complained about the status quo? > > The proposal does not motivate the need for a change well enough. > > (There is a related bug in TH, but that bug can probably simply be > > fixed.) > > * The status quo can be sold as a feature, rather than a short-coming. > > Namely that an operator has a fixed fixity, no matter what namespace > > it lives in. > > This matches morally what other languages do: In Gallina, fixity > > is assigned to names independent of their definition, AFAIK. > > * There is a non-trivial implementation and education overhead, a > > weight that is not pulled by the gains. > > > > If we’d design Haskell from scratch, my verdict might possibly be > > different (but maybe we wouldn’t even allow types and values to share > > names then…) > > > > > > Please contradict me or indicate consensus by staying silent. > > > > > > Greetings, > > Joachim > > > > _______________________________________________ > > ghc-steering-committee mailing list > > ghc-steering-committee at haskell.org > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee at haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee at haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -------------- next part -------------- An HTML attachment was scrubbed... URL: From chak at justtesting.org Tue Oct 17 10:30:19 2017 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Tue, 17 Oct 2017 21:30:19 +1100 Subject: [ghc-steering-committee] Proposal: Type Fixity (#65), Consensus: accept, own language extension? In-Reply-To: References: <1503857788.4643.2.camel@joachim-breitner.de> <1505924631.5913.14.camel@joachim-breitner.de> <1507400762.25530.5.camel@joachim-breitner.de> Message-ID: <1ADEFDFB-BC0F-42E5-AC9D-3A1BF14D1474@justtesting.org> I completely agree with Simon: this is an important question. I think, it would be good to have at least (1), but better (2). Why? Because Haskell’ really doesn’t get anywhere and in its absence the guarantees provided by GHC are the only language stability there is. Maybe it is unfair to put this burden on the compiler, instead of on a separate language specification, but that is how it is. Now, I reckon the main obstacle to (1) and (2) is that LANGUAGE extensions, when they appear first, are in flux, because they are often parts of experiments. Hence, I’d like to suggest that we might be able to lessen the tension between experimentation and stability by formally associating a ”stability” of one of ”alpha”, ”beta”, or ”stable” with each extension. As we all know, these stability annotations don’t work at all on Hackage as nobody ever moves their packages away from ”experimental”. Hence, I suggest that we do not make this the choice of the person who proposes an extension, but part of our process. There are a few options, which might be worth considering. For example, when a LANGUAGE extension is first proposed, it starts at ”alpha”. When latter a proposal is submitted to amend the extension, that amendment is approved by us only if it successfully argues that it improves the maturity of the extension such that it warrants ”beta” stability. And then, the same with ”stable” on the second amendment. Finally, ”stable” language extensions cannot be changed unless it is to fix a grave semantic error or similar. Instead (or in addition) of bumping stability on every new proposal involving the extension, we could also adopt a time (or release) based scheme. Cheers, Manuel PS: BTW, we are pushing for getting to 6 monthly release of GHC. This means that without any guarantees across versions, we would potentially increase variability, which would be bad. > Simon Marlow : > > The main reason I took a position on the issue of extension flags is to force the question: what should LANGUAGE mean? I think it's important to resolve this, to inform future decisions. Here are some options: > > 1. LANGUAGE fully specifies the grammar of the source file > 2. LANGUAGE fully specifies the grammar and semantics of the source file > 3. LANGUAGE tells the compiler what extensions are required, but otherwise provides no guarantees. The source file might not compile with a given version of GHC even if it supports all the extensions listed. In other words, LANGUAGE together with a GHC version range specifies the grammar and semantics of the source file. > > I think what we have right now is 3, because we change the meaning of extensions from version to version of GHC. There are advantages to 1 and 2: for example, if we had 1, then we could parse all of Hackage with haskell-src-exts (or at least identify the subset of source files that can be parsed via their LANGUAGE pragmas). If we had 2, then we could parse, rename and typecheck all of Hackage using haskell-src-exts, haskel-names, and haskell-type-exts. > > Perhaps we want to say that we can only *add* syntax to an existing extension, not change or remove it. This is a variant of 3 that requires only a lower bound on the GHC version required, not an upper bound, and it provides some of the benefits of 1 and 2: you just need a sufficiently recent version of haskell-src-exts et. al. > > Anyway, I mainly wanted to ensure that we're clear about what LANGUAGE means. If we believe the implications of 1 and 2 are too onerous (never changing extensions), so what we want is 3, so be it. > > Cheers > Simon > > > On 10 October 2017 at 03:54, Iavor Diatchki > wrote: > > > > Hello, > > my preference would be to add this to one of the existing extensions (either "explicit namespaces", or "type level operators"). > > Iavor > > > > > > On Sat, Oct 7, 2017 at 11:26 AM Joachim Breitner > wrote: > Hi Committee, > > the discussion has ebbed down again. I observe that a clear majority is > in favor. I don’t think there is a need for a formal vote, so I will > proceed with this decision. > > Simon M brought up the next issue: Shall we require a separate language > extension for this, or can it go under the hood of > `ExplicitNamespaces`? > > So far Simon M expressed a strong preference for the former, while I am > inclined to prefer the latter, and would like to hear a few more > opinions on this detail (which certainly would set precedence for > future decisions). > > Richard brought up the idea of versioned language extensions; that idea > can certainly be investigated, but better independently. We have to > deal with this proposal with the tools we have. > > Greetings, > Joachim > > > Am Mittwoch, den 20.09.2017, 12:23 -0400 schrieb Joachim Breitner: > > Hi, > > > > the type fixity proposal > > (https://github.com/ghc-proposals/ghc-proposals/pull/65 ) > > was met with mixed reactions. > > > > * I recommended rejection and Manuel strongly agrees with me. > > * SPJ does not have strong opinions either way. > > * Richard is in favor, and Iavor agrees. > > > > > > Our process says “If consensus is elusive, then we vote, with the > > Simons retaining veto power.” It looks like this might be such a case. > > Should we go ahead and vote, or is more discussion likely to sway some > > of us? > > > > (I guess I can be swayed towards acceptance, especially if this > > proposal re-uses existing syntactic idioms from export lists with > > ExplicitNamespaces on.) > > > > Greetings, > > Joachim > > > > > > > > Am Sonntag, den 27.08.2017, 20:16 +0200 schrieb Joachim Breitner: > > > Dear Committee, > > > > > > Ryan Scott’s proposal to allow fixity declaration to explicitly target > > > values or types has been brought before us: > > > https://github.com/RyanGlScott/ghc-proposals/blob/type-infix/0000-type-infix.rst > > > https://github.com/ghc-proposals/ghc-proposals/pull/65 > > > > > > I (the secretary) nominates myself as the shepherd, so I can right away > > > continue giving a recommendation. > > > > > > I propose to reject this proposal. The main reasons are: > > > * it is not clear if there is a real use case for this. Has anyone > > > ever complained about the status quo? > > > The proposal does not motivate the need for a change well enough. > > > (There is a related bug in TH, but that bug can probably simply be > > > fixed.) > > > * The status quo can be sold as a feature, rather than a short-coming. > > > Namely that an operator has a fixed fixity, no matter what namespace > > > it lives in. > > > This matches morally what other languages do: In Gallina, fixity > > > is assigned to names independent of their definition, AFAIK. > > > * There is a non-trivial implementation and education overhead, a > > > weight that is not pulled by the gains. > > > > > > If we’d design Haskell from scratch, my verdict might possibly be > > > different (but maybe we wouldn’t even allow types and values to share > > > names then…) > > > > > > > > > Please contradict me or indicate consensus by staying silent. > > > > > > > > > Greetings, > > > Joachim > > > > > > _______________________________________________ > > > ghc-steering-committee mailing list > > > ghc-steering-committee at haskell.org > > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > > > -- > > Joachim Breitner > > mail at joachim-breitner.de > > http://www.joachim-breitner.de/ > > > > _______________________________________________ > > ghc-steering-committee mailing list > > ghc-steering-committee at haskell.org > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at cs.brynmawr.edu Wed Oct 18 03:19:20 2017 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Tue, 17 Oct 2017 23:19:20 -0400 Subject: [ghc-steering-committee] Proposal: Type Fixity (#65), Consensus: accept, own language extension? In-Reply-To: <1ADEFDFB-BC0F-42E5-AC9D-3A1BF14D1474@justtesting.org> References: <1503857788.4643.2.camel@joachim-breitner.de> <1505924631.5913.14.camel@joachim-breitner.de> <1507400762.25530.5.camel@joachim-breitner.de> <1ADEFDFB-BC0F-42E5-AC9D-3A1BF14D1474@justtesting.org> Message-ID: <18ACF281-CC23-4845-99B3-205CF2CC7768@cs.brynmawr.edu> Yes, this is a very important question. Naturally, (2) makes the theorist in me very happy. But I advocate for (3), regardless: - This debate isn't only about extensions. As has been pointed out, `base` undergoes a non-trivial amount of churn between releases, and considering the compiler in a vacuum isn't realistic. Two versions of the compiler will accept (slightly) different versions of the language. (Or, in the case of GHC 7.8, drastically different versions of the language.) - I think we're handicapping ourselves at creating a cutting-edge language if we adopt (1) or (2). (3) allows us to, well, move fast and break things, and that model has been very successful for Haskell thus far. - Who gets hurt if we choose (3)? Surely, (3) means that, e.g., cabal files should properly specify GHC ranges. And we should aim for Simon M's original comment that evolution only adds features -- but we'll never really meet that standard, I don't think. - We could adopt versioned extensions, as I've previously brought up. Doing so might move us more toward (1) or (2). However, I would expect a version of GHC to support only one version of a given extension, and so then a file with, say, `{-# LANGUAGE PolyKinds-3 #-}` would be acceptable by only a small compiler version range (possibly containing only one major release), and then what will we have gained? - I like the idea of having the manual state the stability of extensions. (We should also state unambiguously the potential downside of extensions -- like declaring that UndecidableInstances may cause GHC to loop, but it doesn't allow you to shoot the gorillas.) But I don't think that an extension has to be set in stone after only two revisions. Sometimes experiments really do take years to carry out! So, I like the idea of alpha/beta/stable, but (in contrast to Manuel) I would let the feature designers choose when it's time to move the needle. Looking forward to seeing others' thoughts on this, Richard > On Oct 17, 2017, at 6:30 AM, Manuel M T Chakravarty wrote: > > I completely agree with Simon: this is an important question. > > I think, it would be good to have at least (1), but better (2). > > Why? Because Haskell’ really doesn’t get anywhere and in its absence the guarantees provided by GHC are the only language stability there is. Maybe it is unfair to put this burden on the compiler, instead of on a separate language specification, but that is how it is. > > Now, I reckon the main obstacle to (1) and (2) is that LANGUAGE extensions, when they appear first, are in flux, because they are often parts of experiments. Hence, I’d like to suggest that we might be able to lessen the tension between experimentation and stability by formally associating a ”stability” of one of ”alpha”, ”beta”, or ”stable” with each extension. > > As we all know, these stability annotations don’t work at all on Hackage as nobody ever moves their packages away from ”experimental”. Hence, I suggest that we do not make this the choice of the person who proposes an extension, but part of our process. There are a few options, which might be worth considering. > > For example, when a LANGUAGE extension is first proposed, it starts at ”alpha”. When latter a proposal is submitted to amend the extension, that amendment is approved by us only if it successfully argues that it improves the maturity of the extension such that it warrants ”beta” stability. And then, the same with ”stable” on the second amendment. Finally, ”stable” language extensions cannot be changed unless it is to fix a grave semantic error or similar. > > Instead (or in addition) of bumping stability on every new proposal involving the extension, we could also adopt a time (or release) based scheme. > > Cheers, > Manuel > > PS: BTW, we are pushing for getting to 6 monthly release of GHC. This means that without any guarantees across versions, we would potentially increase variability, which would be bad. > >> Simon Marlow >: >> >> The main reason I took a position on the issue of extension flags is to force the question: what should LANGUAGE mean? I think it's important to resolve this, to inform future decisions. Here are some options: >> >> 1. LANGUAGE fully specifies the grammar of the source file >> 2. LANGUAGE fully specifies the grammar and semantics of the source file >> 3. LANGUAGE tells the compiler what extensions are required, but otherwise provides no guarantees. The source file might not compile with a given version of GHC even if it supports all the extensions listed. In other words, LANGUAGE together with a GHC version range specifies the grammar and semantics of the source file. >> >> I think what we have right now is 3, because we change the meaning of extensions from version to version of GHC. There are advantages to 1 and 2: for example, if we had 1, then we could parse all of Hackage with haskell-src-exts (or at least identify the subset of source files that can be parsed via their LANGUAGE pragmas). If we had 2, then we could parse, rename and typecheck all of Hackage using haskell-src-exts, haskel-names, and haskell-type-exts. >> >> Perhaps we want to say that we can only *add* syntax to an existing extension, not change or remove it. This is a variant of 3 that requires only a lower bound on the GHC version required, not an upper bound, and it provides some of the benefits of 1 and 2: you just need a sufficiently recent version of haskell-src-exts et. al. >> >> Anyway, I mainly wanted to ensure that we're clear about what LANGUAGE means. If we believe the implications of 1 and 2 are too onerous (never changing extensions), so what we want is 3, so be it. >> >> Cheers >> Simon >> >> >> On 10 October 2017 at 03:54, Iavor Diatchki > wrote: >> >> >> >> Hello, >> >> my preference would be to add this to one of the existing extensions (either "explicit namespaces", or "type level operators"). >> >> Iavor >> >> >> >> >> >> On Sat, Oct 7, 2017 at 11:26 AM Joachim Breitner > wrote: >> Hi Committee, >> >> the discussion has ebbed down again. I observe that a clear majority is >> in favor. I don’t think there is a need for a formal vote, so I will >> proceed with this decision. >> >> Simon M brought up the next issue: Shall we require a separate language >> extension for this, or can it go under the hood of >> `ExplicitNamespaces`? >> >> So far Simon M expressed a strong preference for the former, while I am >> inclined to prefer the latter, and would like to hear a few more >> opinions on this detail (which certainly would set precedence for >> future decisions). >> >> Richard brought up the idea of versioned language extensions; that idea >> can certainly be investigated, but better independently. We have to >> deal with this proposal with the tools we have. >> >> Greetings, >> Joachim >> >> >> Am Mittwoch, den 20.09.2017, 12:23 -0400 schrieb Joachim Breitner: >> > Hi, >> > >> > the type fixity proposal >> > (https://github.com/ghc-proposals/ghc-proposals/pull/65 ) >> > was met with mixed reactions. >> > >> > * I recommended rejection and Manuel strongly agrees with me. >> > * SPJ does not have strong opinions either way. >> > * Richard is in favor, and Iavor agrees. >> > >> > >> > Our process says “If consensus is elusive, then we vote, with the >> > Simons retaining veto power.” It looks like this might be such a case. >> > Should we go ahead and vote, or is more discussion likely to sway some >> > of us? >> > >> > (I guess I can be swayed towards acceptance, especially if this >> > proposal re-uses existing syntactic idioms from export lists with >> > ExplicitNamespaces on.) >> > >> > Greetings, >> > Joachim >> > >> > >> > >> > Am Sonntag, den 27.08.2017, 20:16 +0200 schrieb Joachim Breitner: >> > > Dear Committee, >> > > >> > > Ryan Scott’s proposal to allow fixity declaration to explicitly target >> > > values or types has been brought before us: >> > > https://github.com/RyanGlScott/ghc-proposals/blob/type-infix/0000-type-infix.rst >> > > https://github.com/ghc-proposals/ghc-proposals/pull/65 >> > > >> > > I (the secretary) nominates myself as the shepherd, so I can right away >> > > continue giving a recommendation. >> > > >> > > I propose to reject this proposal. The main reasons are: >> > > * it is not clear if there is a real use case for this. Has anyone >> > > ever complained about the status quo? >> > > The proposal does not motivate the need for a change well enough. >> > > (There is a related bug in TH, but that bug can probably simply be >> > > fixed.) >> > > * The status quo can be sold as a feature, rather than a short-coming. >> > > Namely that an operator has a fixed fixity, no matter what namespace >> > > it lives in. >> > > This matches morally what other languages do: In Gallina, fixity >> > > is assigned to names independent of their definition, AFAIK. >> > > * There is a non-trivial implementation and education overhead, a >> > > weight that is not pulled by the gains. >> > > >> > > If we’d design Haskell from scratch, my verdict might possibly be >> > > different (but maybe we wouldn’t even allow types and values to share >> > > names then…) >> > > >> > > >> > > Please contradict me or indicate consensus by staying silent. >> > > >> > > >> > > Greetings, >> > > Joachim >> > > >> > > _______________________________________________ >> > > ghc-steering-committee mailing list >> > > ghc-steering-committee at haskell.org >> > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> > >> > -- >> > Joachim Breitner >> > mail at joachim-breitner.de >> > http://www.joachim-breitner.de/ >> > >> > _______________________________________________ >> > ghc-steering-committee mailing list >> > ghc-steering-committee at haskell.org >> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> -- >> Joachim Breitner >> mail at joachim-breitner.de >> http://www.joachim-breitner.de/ >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> >> >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -------------- next part -------------- An HTML attachment was scrubbed... URL: From rleshchinskiy at gmail.com Wed Oct 18 06:44:32 2017 From: rleshchinskiy at gmail.com (Roman Leschinskiy) Date: Wed, 18 Oct 2017 07:44:32 +0100 Subject: [ghc-steering-committee] Proposal: Type Fixity (#65), Consensus: accept, own language extension? In-Reply-To: <18ACF281-CC23-4845-99B3-205CF2CC7768@cs.brynmawr.edu> References: <1503857788.4643.2.camel@joachim-breitner.de> <1505924631.5913.14.camel@joachim-breitner.de> <1507400762.25530.5.camel@joachim-breitner.de> <1ADEFDFB-BC0F-42E5-AC9D-3A1BF14D1474@justtesting.org> <18ACF281-CC23-4845-99B3-205CF2CC7768@cs.brynmawr.edu> Message-ID: <6F338105-BCD2-4006-BAF0-C786ADCEDA90@gmail.com> How about we take Richard’s suggestion and replace version numbers by years? So we have TypeOperators-2017, TypeFamilies-2017 etc. mean exactly what they mean now. GHC commits to supporting this semantics for, say, 4 years. In 4 years, we drop support for the 2017 extensions and introduce 2021 extensions, again with a 4 year commitment. Meanwhile, just TypeOperators without a year can freely change its meaning. This allows people who care about stability to have it while not impacting cutting edge. Roman > On 18 Oct 2017, at 04:19, Richard Eisenberg wrote: > > Yes, this is a very important question. > > Naturally, (2) makes the theorist in me very happy. But I advocate for (3), regardless: > > - This debate isn't only about extensions. As has been pointed out, `base` undergoes a non-trivial amount of churn between releases, and considering the compiler in a vacuum isn't realistic. Two versions of the compiler will accept (slightly) different versions of the language. (Or, in the case of GHC 7.8, drastically different versions of the language.) > > - I think we're handicapping ourselves at creating a cutting-edge language if we adopt (1) or (2). (3) allows us to, well, move fast and break things, and that model has been very successful for Haskell thus far. > > - Who gets hurt if we choose (3)? Surely, (3) means that, e.g., cabal files should properly specify GHC ranges. And we should aim for Simon M's original comment that evolution only adds features -- but we'll never really meet that standard, I don't think. > > - We could adopt versioned extensions, as I've previously brought up. Doing so might move us more toward (1) or (2). However, I would expect a version of GHC to support only one version of a given extension, and so then a file with, say, `{-# LANGUAGE PolyKinds-3 #-}` would be acceptable by only a small compiler version range (possibly containing only one major release), and then what will we have gained? > > - I like the idea of having the manual state the stability of extensions. (We should also state unambiguously the potential downside of extensions -- like declaring that UndecidableInstances may cause GHC to loop, but it doesn't allow you to shoot the gorillas.) But I don't think that an extension has to be set in stone after only two revisions. Sometimes experiments really do take years to carry out! So, I like the idea of alpha/beta/stable, but (in contrast to Manuel) I would let the feature designers choose when it's time to move the needle. > > Looking forward to seeing others' thoughts on this, > Richard > >> On Oct 17, 2017, at 6:30 AM, Manuel M T Chakravarty wrote: >> >> I completely agree with Simon: this is an important question. >> >> I think, it would be good to have at least (1), but better (2). >> >> Why? Because Haskell’ really doesn’t get anywhere and in its absence the guarantees provided by GHC are the only language stability there is. Maybe it is unfair to put this burden on the compiler, instead of on a separate language specification, but that is how it is. >> >> Now, I reckon the main obstacle to (1) and (2) is that LANGUAGE extensions, when they appear first, are in flux, because they are often parts of experiments. Hence, I’d like to suggest that we might be able to lessen the tension between experimentation and stability by formally associating a ”stability” of one of ”alpha”, ”beta”, or ”stable” with each extension. >> >> As we all know, these stability annotations don’t work at all on Hackage as nobody ever moves their packages away from ”experimental”. Hence, I suggest that we do not make this the choice of the person who proposes an extension, but part of our process. There are a few options, which might be worth considering. >> >> For example, when a LANGUAGE extension is first proposed, it starts at ”alpha”. When latter a proposal is submitted to amend the extension, that amendment is approved by us only if it successfully argues that it improves the maturity of the extension such that it warrants ”beta” stability. And then, the same with ”stable” on the second amendment. Finally, ”stable” language extensions cannot be changed unless it is to fix a grave semantic error or similar. >> >> Instead (or in addition) of bumping stability on every new proposal involving the extension, we could also adopt a time (or release) based scheme. >> >> Cheers, >> Manuel >> >> PS: BTW, we are pushing for getting to 6 monthly release of GHC. This means that without any guarantees across versions, we would potentially increase variability, which would be bad. >> >>> Simon Marlow : >>> >>> The main reason I took a position on the issue of extension flags is to force the question: what should LANGUAGE mean? I think it's important to resolve this, to inform future decisions. Here are some options: >>> >>> 1. LANGUAGE fully specifies the grammar of the source file >>> 2. LANGUAGE fully specifies the grammar and semantics of the source file >>> 3. LANGUAGE tells the compiler what extensions are required, but otherwise provides no guarantees. The source file might not compile with a given version of GHC even if it supports all the extensions listed. In other words, LANGUAGE together with a GHC version range specifies the grammar and semantics of the source file. >>> >>> I think what we have right now is 3, because we change the meaning of extensions from version to version of GHC. There are advantages to 1 and 2: for example, if we had 1, then we could parse all of Hackage with haskell-src-exts (or at least identify the subset of source files that can be parsed via their LANGUAGE pragmas). If we had 2, then we could parse, rename and typecheck all of Hackage using haskell-src-exts, haskel-names, and haskell-type-exts. >>> >>> Perhaps we want to say that we can only *add* syntax to an existing extension, not change or remove it. This is a variant of 3 that requires only a lower bound on the GHC version required, not an upper bound, and it provides some of the benefits of 1 and 2: you just need a sufficiently recent version of haskell-src-exts et. al. >>> >>> Anyway, I mainly wanted to ensure that we're clear about what LANGUAGE means. If we believe the implications of 1 and 2 are too onerous (never changing extensions), so what we want is 3, so be it. >>> >>> Cheers >>> Simon >>> >>> >>>> On 10 October 2017 at 03:54, Iavor Diatchki wrote: >>>> >>>> >>>> >>>> Hello, >>>> >>>> my preference would be to add this to one of the existing extensions (either "explicit namespaces", or "type level operators"). >>>> >>>> Iavor >>>> >>>> >>>> >>>> >>>> >>>>> On Sat, Oct 7, 2017 at 11:26 AM Joachim Breitner wrote: >>>>> Hi Committee, >>>>> >>>>> the discussion has ebbed down again. I observe that a clear majority is >>>>> in favor. I don’t think there is a need for a formal vote, so I will >>>>> proceed with this decision. >>>>> >>>>> Simon M brought up the next issue: Shall we require a separate language >>>>> extension for this, or can it go under the hood of >>>>> `ExplicitNamespaces`? >>>>> >>>>> So far Simon M expressed a strong preference for the former, while I am >>>>> inclined to prefer the latter, and would like to hear a few more >>>>> opinions on this detail (which certainly would set precedence for >>>>> future decisions). >>>>> >>>>> Richard brought up the idea of versioned language extensions; that idea >>>>> can certainly be investigated, but better independently. We have to >>>>> deal with this proposal with the tools we have. >>>>> >>>>> Greetings, >>>>> Joachim >>>>> >>>>> >>>>> Am Mittwoch, den 20.09.2017, 12:23 -0400 schrieb Joachim Breitner: >>>>> > Hi, >>>>> > >>>>> > the type fixity proposal >>>>> > (https://github.com/ghc-proposals/ghc-proposals/pull/65) >>>>> > was met with mixed reactions. >>>>> > >>>>> > * I recommended rejection and Manuel strongly agrees with me. >>>>> > * SPJ does not have strong opinions either way. >>>>> > * Richard is in favor, and Iavor agrees. >>>>> > >>>>> > >>>>> > Our process says “If consensus is elusive, then we vote, with the >>>>> > Simons retaining veto power.” It looks like this might be such a case. >>>>> > Should we go ahead and vote, or is more discussion likely to sway some >>>>> > of us? >>>>> > >>>>> > (I guess I can be swayed towards acceptance, especially if this >>>>> > proposal re-uses existing syntactic idioms from export lists with >>>>> > ExplicitNamespaces on.) >>>>> > >>>>> > Greetings, >>>>> > Joachim >>>>> > >>>>> > >>>>> > >>>>> > Am Sonntag, den 27.08.2017, 20:16 +0200 schrieb Joachim Breitner: >>>>> > > Dear Committee, >>>>> > > >>>>> > > Ryan Scott’s proposal to allow fixity declaration to explicitly target >>>>> > > values or types has been brought before us: >>>>> > > https://github.com/RyanGlScott/ghc-proposals/blob/type-infix/0000-type-infix.rst >>>>> > > https://github.com/ghc-proposals/ghc-proposals/pull/65 >>>>> > > >>>>> > > I (the secretary) nominates myself as the shepherd, so I can right away >>>>> > > continue giving a recommendation. >>>>> > > >>>>> > > I propose to reject this proposal. The main reasons are: >>>>> > > * it is not clear if there is a real use case for this. Has anyone >>>>> > > ever complained about the status quo? >>>>> > > The proposal does not motivate the need for a change well enough. >>>>> > > (There is a related bug in TH, but that bug can probably simply be >>>>> > > fixed.) >>>>> > > * The status quo can be sold as a feature, rather than a short-coming. >>>>> > > Namely that an operator has a fixed fixity, no matter what namespace >>>>> > > it lives in. >>>>> > > This matches morally what other languages do: In Gallina, fixity >>>>> > > is assigned to names independent of their definition, AFAIK. >>>>> > > * There is a non-trivial implementation and education overhead, a >>>>> > > weight that is not pulled by the gains. >>>>> > > >>>>> > > If we’d design Haskell from scratch, my verdict might possibly be >>>>> > > different (but maybe we wouldn’t even allow types and values to share >>>>> > > names then…) >>>>> > > >>>>> > > >>>>> > > Please contradict me or indicate consensus by staying silent. >>>>> > > >>>>> > > >>>>> > > Greetings, >>>>> > > Joachim >>>>> > > >>>>> > > _______________________________________________ >>>>> > > ghc-steering-committee mailing list >>>>> > > ghc-steering-committee at haskell.org >>>>> > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>>>> > >>>>> > -- >>>>> > Joachim Breitner >>>>> > mail at joachim-breitner.de >>>>> > http://www.joachim-breitner.de/ >>>>> > >>>>> > _______________________________________________ >>>>> > ghc-steering-committee mailing list >>>>> > ghc-steering-committee at haskell.org >>>>> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>>>> -- >>>>> Joachim Breitner >>>>> mail at joachim-breitner.de >>>>> http://www.joachim-breitner.de/ >>>>> _______________________________________________ >>>>> ghc-steering-committee mailing list >>>>> ghc-steering-committee at haskell.org >>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>>> >>>> _______________________________________________ >>>> ghc-steering-committee mailing list >>>> ghc-steering-committee at haskell.org >>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>>> >>> >>> _______________________________________________ >>> ghc-steering-committee mailing list >>> ghc-steering-committee at haskell.org >>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at cs.brynmawr.edu Wed Oct 18 14:08:53 2017 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Wed, 18 Oct 2017 10:08:53 -0400 Subject: [ghc-steering-committee] Proposal: Type Fixity (#65), Consensus: accept, own language extension? In-Reply-To: <6F338105-BCD2-4006-BAF0-C786ADCEDA90@gmail.com> References: <1503857788.4643.2.camel@joachim-breitner.de> <1505924631.5913.14.camel@joachim-breitner.de> <1507400762.25530.5.camel@joachim-breitner.de> <1ADEFDFB-BC0F-42E5-AC9D-3A1BF14D1474@justtesting.org> <18ACF281-CC23-4845-99B3-205CF2CC7768@cs.brynmawr.edu> <6F338105-BCD2-4006-BAF0-C786ADCEDA90@gmail.com> Message-ID: <5445BC95-9DAC-4CF2-909F-910814D7C467@cs.brynmawr.edu> > On Oct 18, 2017, at 2:44 AM, Roman Leschinskiy wrote: > > GHC commits to supporting this semantics for, say, 4 years. This is a very large commitment, in my view. Maintaining subtle differences in extensions is hard work, especially when the differences are not syntactic (which are admittedly much easier). For example, there have been quite a few bugs in keeping -XTypeInType and -XPolyKinds separate, and I don't think we have it fully working yet. There's one unstated assumption behind all this, for me: we're very, very, very cautious about ever changing the *dynamic* semantics (i.e. runtime behavior) between releases. That's potentially disastrous. It's annoying and frustrating when one version of GHC accepts a program while another rejects. But someone downstream can work around this, either with CPP or with cabal/stack settings that dictate GHC versions. However, a runtime behavior change might go uncaught and cause real bugs. So, when I say I advocate for Simon M's (3), I really mean 4. LANGUAGE tells the compiler what extensions are required and -- if the program is accepted -- its runtime behavior, but otherwise provides no guarantees. The source file might not compile with a given version of GHC even if it supports all the extensions listed. In other words, LANGUAGE together with a GHC version range specifies the grammar and static semantics of the source file. However, LANGUAGE alone (without the version range) specifies the runtime behavior of any resulting code. (This is just a small delta on Simon M's (3) with clarity around runtime behavior.) I'd love feedback from the more industrial users here. It's unsurprising that, from my viewpoint, I would advocate for looser guarantees. But part of why I think looser guarantees are OK is that I thought Stack had basically solved this problem for industrial users, in that several collaborators on a project have a stack.yaml that (among other things) fixes the GHC version. Yes, that team will occasionally want to upgrade, but upgrading will always cause some problems, problems that we as the GHC committee will work to mitigate. Until we take Java's approach to backward compatibility (I hope that's a long long way off!), upgrading will cause problems, no matter which of (1)-(4) we adopt. Richard From iavor.diatchki at gmail.com Wed Oct 18 17:42:05 2017 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Wed, 18 Oct 2017 17:42:05 +0000 Subject: [ghc-steering-committee] Proposal: Type Fixity (#65), Consensus: accept, own language extension? In-Reply-To: <5445BC95-9DAC-4CF2-909F-910814D7C467@cs.brynmawr.edu> References: <1503857788.4643.2.camel@joachim-breitner.de> <1505924631.5913.14.camel@joachim-breitner.de> <1507400762.25530.5.camel@joachim-breitner.de> <1ADEFDFB-BC0F-42E5-AC9D-3A1BF14D1474@justtesting.org> <18ACF281-CC23-4845-99B3-205CF2CC7768@cs.brynmawr.edu> <6F338105-BCD2-4006-BAF0-C786ADCEDA90@gmail.com> <5445BC95-9DAC-4CF2-909F-910814D7C467@cs.brynmawr.edu> Message-ID: Hello, in my view, there are two slightly different issues here: 1) experimenting with language changes, and 2) having a "modular language". We are using a single mechanism---`language` pragmas---to achieve both, which is where the tension lies. When language extensions are first born, they seem to be very much in use case 1) and I think we should allow ourselves to change them, improve them, and even remove them. I also find use case 2 quite useful: I sometimes think of GHC as implementing a family of languages, made out of modular blocks that all work well together, and `language` pragmas in a module document which language configuration is being used. I think that's very cool and makes GHC somewhat unique. Given that we have to balance these two goals, my preference would be that we adopt option (3) where we do allow some changes to extensions, but be cautious if these might seriously conflict with options (1) and (2). So we'd have to exercise judgment on a case by case basis. To be honest, I don't really like the idea of having versions for extensions---I'd rather simply have different names for them if that's what we'd like to do. Here is another idea which might help with this problem somewhat (and I've wanted something like this for other reasons too): we could provide a mechanism for naming sets of language extensions. If we had such a mechanism, I'd be a lot keener on simply adding new extensions, rather than modifying old ones. This would allow us to specify various language standards succinctly---as simply a collection of language extensions, and it would also allow companies or projects to have their own sets of "approved" extensions. Finally, in GHC some extensions already behave a little like this, in that some extensions automatically enable others---it would be nice if one could look up these definitions somewhere, without having to look in the compiler's source code. -Iavor On Wed, Oct 18, 2017 at 7:08 AM Richard Eisenberg wrote: > > > On Oct 18, 2017, at 2:44 AM, Roman Leschinskiy > wrote: > > > > GHC commits to supporting this semantics for, say, 4 years. > > This is a very large commitment, in my view. Maintaining subtle > differences in extensions is hard work, especially when the differences are > not syntactic (which are admittedly much easier). For example, there have > been quite a few bugs in keeping -XTypeInType and -XPolyKinds separate, and > I don't think we have it fully working yet. > > There's one unstated assumption behind all this, for me: we're very, very, > very cautious about ever changing the *dynamic* semantics (i.e. runtime > behavior) between releases. That's potentially disastrous. It's annoying > and frustrating when one version of GHC accepts a program while another > rejects. But someone downstream can work around this, either with CPP or > with cabal/stack settings that dictate GHC versions. However, a runtime > behavior change might go uncaught and cause real bugs. So, when I say I > advocate for Simon M's (3), I really mean > > 4. LANGUAGE tells the compiler what extensions are required and -- if the > program is accepted -- its runtime behavior, but otherwise provides no > guarantees. The source file might not compile with a given version of GHC > even if it supports all the extensions listed. In other words, LANGUAGE > together with a GHC version range specifies the grammar and static > semantics of the source file. However, LANGUAGE alone (without the version > range) specifies the runtime behavior of any resulting code. > > (This is just a small delta on Simon M's (3) with clarity around runtime > behavior.) > > I'd love feedback from the more industrial users here. It's unsurprising > that, from my viewpoint, I would advocate for looser guarantees. But part > of why I think looser guarantees are OK is that I thought Stack had > basically solved this problem for industrial users, in that several > collaborators on a project have a stack.yaml that (among other things) > fixes the GHC version. Yes, that team will occasionally want to upgrade, > but upgrading will always cause some problems, problems that we as the GHC > committee will work to mitigate. Until we take Java's approach to backward > compatibility (I hope that's a long long way off!), upgrading will cause > problems, no matter which of (1)-(4) we adopt. > > Richard > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rleshchinskiy at gmail.com Wed Oct 18 19:36:13 2017 From: rleshchinskiy at gmail.com (Roman Leshchinskiy) Date: Wed, 18 Oct 2017 20:36:13 +0100 Subject: [ghc-steering-committee] Proposal: Type Fixity (#65), Consensus: accept, own language extension? In-Reply-To: <5445BC95-9DAC-4CF2-909F-910814D7C467@cs.brynmawr.edu> References: <1503857788.4643.2.camel@joachim-breitner.de> <1505924631.5913.14.camel@joachim-breitner.de> <1507400762.25530.5.camel@joachim-breitner.de> <1ADEFDFB-BC0F-42E5-AC9D-3A1BF14D1474@justtesting.org> <18ACF281-CC23-4845-99B3-205CF2CC7768@cs.brynmawr.edu> <6F338105-BCD2-4006-BAF0-C786ADCEDA90@gmail.com> <5445BC95-9DAC-4CF2-909F-910814D7C467@cs.brynmawr.edu> Message-ID: On Wed, Oct 18, 2017 at 3:08 PM, Richard Eisenberg wrote: > >> On Oct 18, 2017, at 2:44 AM, Roman Leschinskiy wrote: >> >> GHC commits to supporting this semantics for, say, 4 years. > > This is a very large commitment, in my view. It is indeed a commitment but there must be some commitment to stability. If the Haskell' committee came up with Haskell 2017, surely GHC would commit to supporting that. Alas, that isn't happening but there has to be a stable language which goes beyond Haskell 2010. It would be good if GHC took some initiative there. I do very much appreciate that it's more work but it's something that an industrial-strength compiler like GHC ought to provide, in my view. Imagine you have a very large code base, a large team working on it and other teams which work on bits of it. To maintain sanity, you have to ensure that everything is written in one dialect. You might pick Haskell 2010 but you'd be missing a lot of fairly crucial (at least, in my view) functionality. So you pick a blessed set of extensions which you enable by default and you disable everything else. Now, after a couple of years you decide to upgrade GHC. This is already a lot of work due to changes in RTS behaviour, dynamic linking, memory consumption etc. You'd *really* like your code to at least still compile and run. At the moment, it typically doesn't, unfortunately. > For example, there have been quite a few bugs in keeping -XTypeInType and -XPolyKinds separate, and I don't think we have it fully working yet. This is (I think) exactly a case where, say, an -XPolyKinds-2017 would be helpful. It's not a problem if it turns on more than just PolyKinds. What's problematic is if a later version of GHC breaks your code because the meaning of the extension changed (even if it's now more correct than it used to be). Note that I don't advocate bug compatibility. I'd just like to be able to enable -XThis and have the assurance that GHC devs will *try* to maintain its semantics for a few years. > Yes, that team will occasionally want to upgrade, but upgrading will always cause some problems, problems that we as the GHC committee will work to mitigate. Until we take Java's approach to backward compatibility (I hope that's a long long way off!), upgrading will cause problems, no matter which of (1)-(4) we adopt. There will always be some problems, yes, but problems like "20 modules sprinkled throughout my code base fail with weird type errors because -XThis no longer implies -XThat" are unnecessary and can be largely avoided by providing a stable dialect. How often you can upgrade GHC directly depends on how much pain an upgrade causes. For at least one commercial user, that frequency is currently around once every 3 years solely because of how painful upgrades are. Of course, the real fix for this is to have a proper language standard. I'm just proposing a partial workaround for not having one. Roman From rae at cs.brynmawr.edu Wed Oct 18 19:44:47 2017 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Wed, 18 Oct 2017 15:44:47 -0400 Subject: [ghc-steering-committee] Proposal: Type Fixity (#65), Consensus: accept, own language extension? In-Reply-To: References: <1503857788.4643.2.camel@joachim-breitner.de> <1505924631.5913.14.camel@joachim-breitner.de> <1507400762.25530.5.camel@joachim-breitner.de> <1ADEFDFB-BC0F-42E5-AC9D-3A1BF14D1474@justtesting.org> <18ACF281-CC23-4845-99B3-205CF2CC7768@cs.brynmawr.edu> <6F338105-BCD2-4006-BAF0-C786ADCEDA90@gmail.com> <5445BC95-9DAC-4CF2-909F-910814D7C467@cs.brynmawr.edu> Message-ID: <435934B1-AA52-4A56-B911-7FBAA60B04F1@cs.brynmawr.edu> I think with one tweak, Roman and I could be in nice agreement: list only a subset of extensions as stable. For example, I think RankNTypes is nice and stable. Depending on your level of tolerance for possible problems, GADTs might also be stable. (We *don't* have a specification of that extension, despite trying.) I don't think anyone would argue that PolyKinds is stable, even before GHC 8 came along. Would that satisfy everyone? GHC can advertise a subset of extensions for which Simon M's (1) and (2) hold; the rest of the extensions are like Simon M's (3). We, as a committee, are responsible for this labeling and for keeping it up to date. Perhaps we could even have a public place where users could request that we label some extension as stable and we could consider the request. Richard > On Oct 18, 2017, at 3:36 PM, Roman Leshchinskiy wrote: > > On Wed, Oct 18, 2017 at 3:08 PM, Richard Eisenberg wrote: >> >>> On Oct 18, 2017, at 2:44 AM, Roman Leschinskiy wrote: >>> >>> GHC commits to supporting this semantics for, say, 4 years. >> >> This is a very large commitment, in my view. > > It is indeed a commitment but there must be some commitment to > stability. If the Haskell' committee came up with Haskell 2017, surely > GHC would commit to supporting that. Alas, that isn't happening but > there has to be a stable language which goes beyond Haskell 2010. It > would be good if GHC took some initiative there. > > I do very much appreciate that it's more work but it's something that > an industrial-strength compiler like GHC ought to provide, in my view. > > Imagine you have a very large code base, a large team working on it > and other teams which work on bits of it. To maintain sanity, you have > to ensure that everything is written in one dialect. You might pick > Haskell 2010 but you'd be missing a lot of fairly crucial (at least, > in my view) functionality. So you pick a blessed set of extensions > which you enable by default and you disable everything else. > > Now, after a couple of years you decide to upgrade GHC. This is > already a lot of work due to changes in RTS behaviour, dynamic > linking, memory consumption etc. You'd *really* like your code to at > least still compile and run. At the moment, it typically doesn't, > unfortunately. > >> For example, there have been quite a few bugs in keeping -XTypeInType and -XPolyKinds separate, and I don't think we have it fully working yet. > > This is (I think) exactly a case where, say, an -XPolyKinds-2017 would > be helpful. It's not a problem if it turns on more than just > PolyKinds. What's problematic is if a later version of GHC breaks your > code because the meaning of the extension changed (even if it's now > more correct than it used to be). > > Note that I don't advocate bug compatibility. I'd just like to be able > to enable -XThis and have the assurance that GHC devs will *try* to > maintain its semantics for a few years. > >> Yes, that team will occasionally want to upgrade, but upgrading will always cause some problems, problems that we as the GHC committee will work to mitigate. Until we take Java's approach to backward compatibility (I hope that's a long long way off!), upgrading will cause problems, no matter which of (1)-(4) we adopt. > > There will always be some problems, yes, but problems like "20 modules > sprinkled throughout my code base fail with weird type errors because > -XThis no longer implies -XThat" are unnecessary and can be largely > avoided by providing a stable dialect. > > How often you can upgrade GHC directly depends on how much pain an > upgrade causes. For at least one commercial user, that frequency is > currently around once every 3 years solely because of how painful > upgrades are. > > Of course, the real fix for this is to have a proper language > standard. I'm just proposing a partial workaround for not having one. > > Roman From mail at joachim-breitner.de Wed Oct 18 20:49:39 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 18 Oct 2017 16:49:39 -0400 Subject: [ghc-steering-committee] Proposal: Type Fixity (#65), Consensus: accept, own language extension? In-Reply-To: References: <1503857788.4643.2.camel@joachim-breitner.de> <1505924631.5913.14.camel@joachim-breitner.de> <1507400762.25530.5.camel@joachim-breitner.de> <1ADEFDFB-BC0F-42E5-AC9D-3A1BF14D1474@justtesting.org> <18ACF281-CC23-4845-99B3-205CF2CC7768@cs.brynmawr.edu> <6F338105-BCD2-4006-BAF0-C786ADCEDA90@gmail.com> <5445BC95-9DAC-4CF2-909F-910814D7C467@cs.brynmawr.edu> Message-ID: <1508359779.9354.12.camel@joachim-breitner.de> Hi, Am Mittwoch, den 18.10.2017, 20:36 +0100 schrieb Roman Leshchinskiy: > It is indeed a commitment but there must be some commitment to > stability. If the Haskell' committee came up with Haskell 2017, > surely GHC would commit to supporting that … > Of course, the real fix for this is to have a proper language > standard. I'm just proposing a partial workaround for not having one. I think this implies (and I agree) that it’s the Haskell' committee’s task to take existing language extensions, decide whether they are mature enough to be standardized, go through the work of actually specifying them rigorously. This would yield a distinction between “new, fancy, evolving, use-at-your-own-risk” extensions and “mature, can safely be used in production” extensions. Unfortuantely, Haskell' (AFAIK) not only has do take stability and specificatability into account, but also portability: Does a certain extension makes sense independent of GHC. This is orthogonal to the above, and I expect that there are stable, unportable extensions. So this naturally leads to Richard’s suggestion: Am Mittwoch, den 18.10.2017, 15:44 -0400 schrieb Richard Eisenberg: > I think with one tweak, Roman and I could be in nice agreement: list > only a subset of extensions as stable. For example, I think > RankNTypes is nice and stable. Depending on your level of tolerance > for possible problems, GADTs might also be stable. (We *don't* have a > specification of that extension, despite trying.) I don't think > anyone would argue that PolyKinds is stable, even before GHC 8 came > along > Would that satisfy everyone? GHC can advertise a subset of extensions > for which Simon M's (1) and (2) hold; the rest of the extensions are > like Simon M's (3). We, as a committee, are responsible for this > labeling and for keeping it up to date. This sounds good, mostly. But would we have had the foresight to recognize that the `ExplicitNamespaces` extension was incomplete in the sense that it only applied to import and export lists, when it obviously should have applied to fixity declarations and various pragmas as well? The way out there might be to try our best, and if we get it wrong and mark an extension as stable too early, we’ll just have to add a new pragma for the improved ones… so that seems like a good compromise. The other failure mode would be that we will have _too strict_ requirements for marking extensions as stable, so that production code will inevitably have to use non-stable extensions, and not much is gained. All in all, it might work. > Perhaps we could even have a public place where users could request > that we label some extension as stable and we could consider the > request. Naturally, that could just be a proposal and follow the same process. Regards, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From rae at cs.brynmawr.edu Wed Oct 18 21:17:43 2017 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Wed, 18 Oct 2017 17:17:43 -0400 Subject: [ghc-steering-committee] Proposal: Type Fixity (#65), Consensus: accept, own language extension? In-Reply-To: <1508359779.9354.12.camel@joachim-breitner.de> References: <1503857788.4643.2.camel@joachim-breitner.de> <1505924631.5913.14.camel@joachim-breitner.de> <1507400762.25530.5.camel@joachim-breitner.de> <1ADEFDFB-BC0F-42E5-AC9D-3A1BF14D1474@justtesting.org> <18ACF281-CC23-4845-99B3-205CF2CC7768@cs.brynmawr.edu> <6F338105-BCD2-4006-BAF0-C786ADCEDA90@gmail.com> <5445BC95-9DAC-4CF2-909F-910814D7C467@cs.brynmawr.edu> <1508359779.9354.12.camel@joachim-breitner.de> Message-ID: <0D402BA4-93C4-45C9-B35C-C4516C5B6304@cs.brynmawr.edu> > On Oct 18, 2017, at 4:49 PM, Joachim Breitner wrote: > > The way out there might be to try our best, and if we get it wrong and > mark an extension as stable too early, we’ll just have to add a new > pragma for the improved ones… so that seems like a good compromise. > Yes, this is exactly what I was thinking. For example, TypeFamilies might have been marked as stable before closed type families came about... but then we would just have -XClosedTypeFamilies -- not so horrible. > The other failure mode would be that we will have _too strict_ > requirements for marking extensions as stable, so that production code > will inevitably have to use non-stable extensions, and not much is > gained. This, too, is exactly what I was thinking. Industrial users and book authors have the most to gain from an extension being marked as stable. I would expect that proposals would come from these groups marking extensions as stable, and then we could have a debate. Richard From chak at justtesting.org Thu Oct 19 00:33:16 2017 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Thu, 19 Oct 2017 11:33:16 +1100 Subject: [ghc-steering-committee] Fwd: Proposal: Type Fixity (#65), Consensus: accept, own language extension? References: Message-ID: <5BAD0623-0665-4D7E-A1CD-3376A7B8FCAD@justtesting.org> Mathieu asked me to relay this message to the committee. > Forwarded message > > From: "Boespflug, Mathieu" > Subject: Re: [ghc-steering-committee] Proposal: Type Fixity (#65), Consensus: accept, own language extension? > Date: 18. Oktober 2017 um 21:34:12 GMT+11 > To: Manuel M T Chakravarty > Cc: Facundo Domínguez > > Hi Manuel, > > don't know if I'm allowed to post to this mailing list. So would > appreciate if you could forward the following experience report. > > Facundo and I worked on the -XStaticPointers extension. It has gone > through various improvements/generalizations for each new GHC release. > Eg originally, (static e) evaluated to something of type StaticPtr a, > whereas now it has type IsStatic s => s a, to allow for overloading > (static e) literals similarly to string literals. A corresponding > change was made to base. In the future there might be other changes, > in particular to finally make pointer lookup type safe (it's not, > currently), or to generalize IsStatic to a multi-param type class > (based on real-world experience). Should we have -XStaticPointers1, > -XStaticPointers2, etc for each new variant of this extension any time > we make any improvement to it (which have all been backwards > compatible so far)? That would be pretty onerous. > > Now, -XStaticPointers was added as an "experimental" extension, and so > in a strong sense we still have license to make all manner of changes > to that extension. But aren't they all? Isn't the very reason for > adding things as extensions first (rather than as part of the base > language) so that we can introduce new ideas and experiment with them > in the wild? And if the extension passes the test of widespread > usefulness then we etch in one of the Haskell Report stone tablets? > > Writing modern Haskell already entails a fair amount of bureaucracy > (among which language extension bureaucracy). Many different > variations of the same basic extension may well add to that > bureaucracy a fair bit. And what's more, be intimidating to beginners. > > Best, > -- > Mathieu Boespflug > Founder at http://tweag.io. > > > On 17 October 2017 at 12:30, Manuel M T Chakravarty > wrote: >> I completely agree with Simon: this is an important question. >> >> I think, it would be good to have at least (1), but better (2). >> >> Why? Because Haskell’ really doesn’t get anywhere and in its absence the >> guarantees provided by GHC are the only language stability there is. Maybe >> it is unfair to put this burden on the compiler, instead of on a separate >> language specification, but that is how it is. >> >> Now, I reckon the main obstacle to (1) and (2) is that LANGUAGE extensions, >> when they appear first, are in flux, because they are often parts of >> experiments. Hence, I’d like to suggest that we might be able to lessen the >> tension between experimentation and stability by formally associating a >> ”stability” of one of ”alpha”, ”beta”, or ”stable” with each extension. >> >> As we all know, these stability annotations don’t work at all on Hackage as >> nobody ever moves their packages away from ”experimental”. Hence, I suggest >> that we do not make this the choice of the person who proposes an extension, >> but part of our process. There are a few options, which might be worth >> considering. >> >> For example, when a LANGUAGE extension is first proposed, it starts at >> ”alpha”. When latter a proposal is submitted to amend the extension, that >> amendment is approved by us only if it successfully argues that it improves >> the maturity of the extension such that it warrants ”beta” stability. And >> then, the same with ”stable” on the second amendment. Finally, ”stable” >> language extensions cannot be changed unless it is to fix a grave semantic >> error or similar. >> >> Instead (or in addition) of bumping stability on every new proposal >> involving the extension, we could also adopt a time (or release) based >> scheme. >> >> Cheers, >> Manuel >> >> PS: BTW, we are pushing for getting to 6 monthly release of GHC. This means >> that without any guarantees across versions, we would potentially increase >> variability, which would be bad. >> >> Simon Marlow : >> >> The main reason I took a position on the issue of extension flags is to >> force the question: what should LANGUAGE mean? I think it's important to >> resolve this, to inform future decisions. Here are some options: >> >> 1. LANGUAGE fully specifies the grammar of the source file >> 2. LANGUAGE fully specifies the grammar and semantics of the source file >> 3. LANGUAGE tells the compiler what extensions are required, but otherwise >> provides no guarantees. The source file might not compile with a given >> version of GHC even if it supports all the extensions listed. In other >> words, LANGUAGE together with a GHC version range specifies the grammar and >> semantics of the source file. >> >> I think what we have right now is 3, because we change the meaning of >> extensions from version to version of GHC. There are advantages to 1 and 2: >> for example, if we had 1, then we could parse all of Hackage with >> haskell-src-exts (or at least identify the subset of source files that can >> be parsed via their LANGUAGE pragmas). If we had 2, then we could parse, >> rename and typecheck all of Hackage using haskell-src-exts, haskel-names, >> and haskell-type-exts. >> >> Perhaps we want to say that we can only *add* syntax to an existing >> extension, not change or remove it. This is a variant of 3 that requires >> only a lower bound on the GHC version required, not an upper bound, and it >> provides some of the benefits of 1 and 2: you just need a sufficiently >> recent version of haskell-src-exts et. al. >> >> Anyway, I mainly wanted to ensure that we're clear about what LANGUAGE >> means. If we believe the implications of 1 and 2 are too onerous (never >> changing extensions), so what we want is 3, so be it. >> >> Cheers >> Simon >> >> >> On 10 October 2017 at 03:54, Iavor Diatchki >> wrote: >>> >>> >>> >>> >>> Hello, >>> >>> my preference would be to add this to one of the existing extensions >>> (either "explicit namespaces", or "type level operators"). >>> >>> Iavor >>> >>> >>> >>> >>> >>> On Sat, Oct 7, 2017 at 11:26 AM Joachim Breitner >>> wrote: >>>> >>>> Hi Committee, >>>> >>>> the discussion has ebbed down again. I observe that a clear majority is >>>> in favor. I don’t think there is a need for a formal vote, so I will >>>> proceed with this decision. >>>> >>>> Simon M brought up the next issue: Shall we require a separate language >>>> extension for this, or can it go under the hood of >>>> `ExplicitNamespaces`? >>>> >>>> So far Simon M expressed a strong preference for the former, while I am >>>> inclined to prefer the latter, and would like to hear a few more >>>> opinions on this detail (which certainly would set precedence for >>>> future decisions). >>>> >>>> Richard brought up the idea of versioned language extensions; that idea >>>> can certainly be investigated, but better independently. We have to >>>> deal with this proposal with the tools we have. >>>> >>>> Greetings, >>>> Joachim >>>> >>>> >>>> Am Mittwoch, den 20.09.2017, 12:23 -0400 schrieb Joachim Breitner: >>>>> Hi, >>>>> >>>>> the type fixity proposal >>>>> (https://github.com/ghc-proposals/ghc-proposals/pull/65) >>>>> was met with mixed reactions. >>>>> >>>>> * I recommended rejection and Manuel strongly agrees with me. >>>>> * SPJ does not have strong opinions either way. >>>>> * Richard is in favor, and Iavor agrees. >>>>> >>>>> >>>>> Our process says “If consensus is elusive, then we vote, with the >>>>> Simons retaining veto power.” It looks like this might be such a case. >>>>> Should we go ahead and vote, or is more discussion likely to sway some >>>>> of us? >>>>> >>>>> (I guess I can be swayed towards acceptance, especially if this >>>>> proposal re-uses existing syntactic idioms from export lists with >>>>> ExplicitNamespaces on.) >>>>> >>>>> Greetings, >>>>> Joachim >>>>> >>>>> >>>>> >>>>> Am Sonntag, den 27.08.2017, 20:16 +0200 schrieb Joachim Breitner: >>>>>> Dear Committee, >>>>>> >>>>>> Ryan Scott’s proposal to allow fixity declaration to explicitly >>>>>> target >>>>>> values or types has been brought before us: >>>>>> >>>>>> https://github.com/RyanGlScott/ghc-proposals/blob/type-infix/0000-type-infix.rst >>>>>> https://github.com/ghc-proposals/ghc-proposals/pull/65 >>>>>> >>>>>> I (the secretary) nominates myself as the shepherd, so I can right >>>>>> away >>>>>> continue giving a recommendation. >>>>>> >>>>>> I propose to reject this proposal. The main reasons are: >>>>>> * it is not clear if there is a real use case for this. Has anyone >>>>>> ever complained about the status quo? >>>>>> The proposal does not motivate the need for a change well enough. >>>>>> (There is a related bug in TH, but that bug can probably simply be >>>>>> fixed.) >>>>>> * The status quo can be sold as a feature, rather than a >>>>>> short-coming. >>>>>> Namely that an operator has a fixed fixity, no matter what >>>>>> namespace >>>>>> it lives in. >>>>>> This matches morally what other languages do: In Gallina, fixity >>>>>> is assigned to names independent of their definition, AFAIK. >>>>>> * There is a non-trivial implementation and education overhead, a >>>>>> weight that is not pulled by the gains. >>>>>> >>>>>> If we’d design Haskell from scratch, my verdict might possibly be >>>>>> different (but maybe we wouldn’t even allow types and values to share >>>>>> names then…) >>>>>> >>>>>> >>>>>> Please contradict me or indicate consensus by staying silent. >>>>>> >>>>>> >>>>>> Greetings, >>>>>> Joachim >>>>>> >>>>>> _______________________________________________ >>>>>> ghc-steering-committee mailing list >>>>>> ghc-steering-committee at haskell.org >>>>>> >>>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>>>> >>>>> -- >>>>> Joachim Breitner >>>>> mail at joachim-breitner.de >>>>> http://www.joachim-breitner.de/ >>>>> >>>>> _______________________________________________ >>>>> ghc-steering-committee mailing list >>>>> ghc-steering-committee at haskell.org >>>>> >>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>>> -- >>>> Joachim Breitner >>>> mail at joachim-breitner.de >>>> http://www.joachim-breitner.de/ >>>> _______________________________________________ >>>> ghc-steering-committee mailing list >>>> ghc-steering-committee at haskell.org >>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>> >>> >>> _______________________________________________ >>> ghc-steering-committee mailing list >>> ghc-steering-committee at haskell.org >>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>> >> >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> >> >> >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From chak at justtesting.org Thu Oct 19 00:42:07 2017 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Thu, 19 Oct 2017 11:42:07 +1100 Subject: [ghc-steering-committee] Fwd: Proposal: Type Fixity (#65), Consensus: accept, own language extension? In-Reply-To: <5BAD0623-0665-4D7E-A1CD-3376A7B8FCAD@justtesting.org> References: <5BAD0623-0665-4D7E-A1CD-3376A7B8FCAD@justtesting.org> Message-ID: <0C24A31D-DCF4-4584-8EB7-8D38804E2C4F@justtesting.org> My problem with this is that I don’t think that we will get any Haskell Report stone tablets anymore. The idea that extensions slowly migrate into the report when they settle did underlie the rational for being trigger happy about changing them — but it is not working anymore. Hence, I think, we (GHC & the Steering Committee) need to pick up and fix the mess that the Haskell Prime effort left us with. Cheers, Manuel > Manuel M T Chakravarty : > > Mathieu asked me to relay this message to the committee. > >> Forwarded message >> >> From: "Boespflug, Mathieu" > >> Subject: Re: [ghc-steering-committee] Proposal: Type Fixity (#65), Consensus: accept, own language extension? >> Date: 18. Oktober 2017 um 21:34:12 GMT+11 >> To: Manuel M T Chakravarty > >> Cc: Facundo Domínguez > >> >> Hi Manuel, >> >> don't know if I'm allowed to post to this mailing list. So would >> appreciate if you could forward the following experience report. >> >> Facundo and I worked on the -XStaticPointers extension. It has gone >> through various improvements/generalizations for each new GHC release. >> Eg originally, (static e) evaluated to something of type StaticPtr a, >> whereas now it has type IsStatic s => s a, to allow for overloading >> (static e) literals similarly to string literals. A corresponding >> change was made to base. In the future there might be other changes, >> in particular to finally make pointer lookup type safe (it's not, >> currently), or to generalize IsStatic to a multi-param type class >> (based on real-world experience). Should we have -XStaticPointers1, >> -XStaticPointers2, etc for each new variant of this extension any time >> we make any improvement to it (which have all been backwards >> compatible so far)? That would be pretty onerous. >> >> Now, -XStaticPointers was added as an "experimental" extension, and so >> in a strong sense we still have license to make all manner of changes >> to that extension. But aren't they all? Isn't the very reason for >> adding things as extensions first (rather than as part of the base >> language) so that we can introduce new ideas and experiment with them >> in the wild? And if the extension passes the test of widespread >> usefulness then we etch in one of the Haskell Report stone tablets? >> >> Writing modern Haskell already entails a fair amount of bureaucracy >> (among which language extension bureaucracy). Many different >> variations of the same basic extension may well add to that >> bureaucracy a fair bit. And what's more, be intimidating to beginners. >> >> Best, >> -- >> Mathieu Boespflug >> Founder at http://tweag.io . >> >> >> On 17 October 2017 at 12:30, Manuel M T Chakravarty >> > wrote: >>> I completely agree with Simon: this is an important question. >>> >>> I think, it would be good to have at least (1), but better (2). >>> >>> Why? Because Haskell’ really doesn’t get anywhere and in its absence the >>> guarantees provided by GHC are the only language stability there is. Maybe >>> it is unfair to put this burden on the compiler, instead of on a separate >>> language specification, but that is how it is. >>> >>> Now, I reckon the main obstacle to (1) and (2) is that LANGUAGE extensions, >>> when they appear first, are in flux, because they are often parts of >>> experiments. Hence, I’d like to suggest that we might be able to lessen the >>> tension between experimentation and stability by formally associating a >>> ”stability” of one of ”alpha”, ”beta”, or ”stable” with each extension. >>> >>> As we all know, these stability annotations don’t work at all on Hackage as >>> nobody ever moves their packages away from ”experimental”. Hence, I suggest >>> that we do not make this the choice of the person who proposes an extension, >>> but part of our process. There are a few options, which might be worth >>> considering. >>> >>> For example, when a LANGUAGE extension is first proposed, it starts at >>> ”alpha”. When latter a proposal is submitted to amend the extension, that >>> amendment is approved by us only if it successfully argues that it improves >>> the maturity of the extension such that it warrants ”beta” stability. And >>> then, the same with ”stable” on the second amendment. Finally, ”stable” >>> language extensions cannot be changed unless it is to fix a grave semantic >>> error or similar. >>> >>> Instead (or in addition) of bumping stability on every new proposal >>> involving the extension, we could also adopt a time (or release) based >>> scheme. >>> >>> Cheers, >>> Manuel >>> >>> PS: BTW, we are pushing for getting to 6 monthly release of GHC. This means >>> that without any guarantees across versions, we would potentially increase >>> variability, which would be bad. >>> >>> Simon Marlow >: >>> >>> The main reason I took a position on the issue of extension flags is to >>> force the question: what should LANGUAGE mean? I think it's important to >>> resolve this, to inform future decisions. Here are some options: >>> >>> 1. LANGUAGE fully specifies the grammar of the source file >>> 2. LANGUAGE fully specifies the grammar and semantics of the source file >>> 3. LANGUAGE tells the compiler what extensions are required, but otherwise >>> provides no guarantees. The source file might not compile with a given >>> version of GHC even if it supports all the extensions listed. In other >>> words, LANGUAGE together with a GHC version range specifies the grammar and >>> semantics of the source file. >>> >>> I think what we have right now is 3, because we change the meaning of >>> extensions from version to version of GHC. There are advantages to 1 and 2: >>> for example, if we had 1, then we could parse all of Hackage with >>> haskell-src-exts (or at least identify the subset of source files that can >>> be parsed via their LANGUAGE pragmas). If we had 2, then we could parse, >>> rename and typecheck all of Hackage using haskell-src-exts, haskel-names, >>> and haskell-type-exts. >>> >>> Perhaps we want to say that we can only *add* syntax to an existing >>> extension, not change or remove it. This is a variant of 3 that requires >>> only a lower bound on the GHC version required, not an upper bound, and it >>> provides some of the benefits of 1 and 2: you just need a sufficiently >>> recent version of haskell-src-exts et. al. >>> >>> Anyway, I mainly wanted to ensure that we're clear about what LANGUAGE >>> means. If we believe the implications of 1 and 2 are too onerous (never >>> changing extensions), so what we want is 3, so be it. >>> >>> Cheers >>> Simon >>> >>> >>> On 10 October 2017 at 03:54, Iavor Diatchki > >>> wrote: >>>> >>>> >>>> >>>> >>>> Hello, >>>> >>>> my preference would be to add this to one of the existing extensions >>>> (either "explicit namespaces", or "type level operators"). >>>> >>>> Iavor >>>> >>>> >>>> >>>> >>>> >>>> On Sat, Oct 7, 2017 at 11:26 AM Joachim Breitner >>>> > wrote: >>>>> >>>>> Hi Committee, >>>>> >>>>> the discussion has ebbed down again. I observe that a clear majority is >>>>> in favor. I don’t think there is a need for a formal vote, so I will >>>>> proceed with this decision. >>>>> >>>>> Simon M brought up the next issue: Shall we require a separate language >>>>> extension for this, or can it go under the hood of >>>>> `ExplicitNamespaces`? >>>>> >>>>> So far Simon M expressed a strong preference for the former, while I am >>>>> inclined to prefer the latter, and would like to hear a few more >>>>> opinions on this detail (which certainly would set precedence for >>>>> future decisions). >>>>> >>>>> Richard brought up the idea of versioned language extensions; that idea >>>>> can certainly be investigated, but better independently. We have to >>>>> deal with this proposal with the tools we have. >>>>> >>>>> Greetings, >>>>> Joachim >>>>> >>>>> >>>>> Am Mittwoch, den 20.09.2017, 12:23 -0400 schrieb Joachim Breitner: >>>>>> Hi, >>>>>> >>>>>> the type fixity proposal >>>>>> (https://github.com/ghc-proposals/ghc-proposals/pull/65 ) >>>>>> was met with mixed reactions. >>>>>> >>>>>> * I recommended rejection and Manuel strongly agrees with me. >>>>>> * SPJ does not have strong opinions either way. >>>>>> * Richard is in favor, and Iavor agrees. >>>>>> >>>>>> >>>>>> Our process says “If consensus is elusive, then we vote, with the >>>>>> Simons retaining veto power.” It looks like this might be such a case. >>>>>> Should we go ahead and vote, or is more discussion likely to sway some >>>>>> of us? >>>>>> >>>>>> (I guess I can be swayed towards acceptance, especially if this >>>>>> proposal re-uses existing syntactic idioms from export lists with >>>>>> ExplicitNamespaces on.) >>>>>> >>>>>> Greetings, >>>>>> Joachim >>>>>> >>>>>> >>>>>> >>>>>> Am Sonntag, den 27.08.2017, 20:16 +0200 schrieb Joachim Breitner: >>>>>>> Dear Committee, >>>>>>> >>>>>>> Ryan Scott’s proposal to allow fixity declaration to explicitly >>>>>>> target >>>>>>> values or types has been brought before us: >>>>>>> >>>>>>> https://github.com/RyanGlScott/ghc-proposals/blob/type-infix/0000-type-infix.rst >>>>>>> https://github.com/ghc-proposals/ghc-proposals/pull/65 >>>>>>> >>>>>>> I (the secretary) nominates myself as the shepherd, so I can right >>>>>>> away >>>>>>> continue giving a recommendation. >>>>>>> >>>>>>> I propose to reject this proposal. The main reasons are: >>>>>>> * it is not clear if there is a real use case for this. Has anyone >>>>>>> ever complained about the status quo? >>>>>>> The proposal does not motivate the need for a change well enough. >>>>>>> (There is a related bug in TH, but that bug can probably simply be >>>>>>> fixed.) >>>>>>> * The status quo can be sold as a feature, rather than a >>>>>>> short-coming. >>>>>>> Namely that an operator has a fixed fixity, no matter what >>>>>>> namespace >>>>>>> it lives in. >>>>>>> This matches morally what other languages do: In Gallina, fixity >>>>>>> is assigned to names independent of their definition, AFAIK. >>>>>>> * There is a non-trivial implementation and education overhead, a >>>>>>> weight that is not pulled by the gains. >>>>>>> >>>>>>> If we’d design Haskell from scratch, my verdict might possibly be >>>>>>> different (but maybe we wouldn’t even allow types and values to share >>>>>>> names then…) >>>>>>> >>>>>>> >>>>>>> Please contradict me or indicate consensus by staying silent. >>>>>>> >>>>>>> >>>>>>> Greetings, >>>>>>> Joachim >>>>>>> >>>>>>> _______________________________________________ >>>>>>> ghc-steering-committee mailing list >>>>>>> ghc-steering-committee at haskell.org >>>>>>> >>>>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>>>>> >>>>>> -- >>>>>> Joachim Breitner >>>>>> mail at joachim-breitner.de >>>>>> http://www.joachim-breitner.de/ >>>>>> >>>>>> _______________________________________________ >>>>>> ghc-steering-committee mailing list >>>>>> ghc-steering-committee at haskell.org >>>>>> >>>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>>>> -- >>>>> Joachim Breitner >>>>> mail at joachim-breitner.de >>>>> http://www.joachim-breitner.de/ >>>>> _______________________________________________ >>>>> ghc-steering-committee mailing list >>>>> ghc-steering-committee at haskell.org >>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>>> >>>> >>>> _______________________________________________ >>>> ghc-steering-committee mailing list >>>> ghc-steering-committee at haskell.org >>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>>> >>> >>> _______________________________________________ >>> ghc-steering-committee mailing list >>> ghc-steering-committee at haskell.org >>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>> >>> >>> >>> _______________________________________________ >>> ghc-steering-committee mailing list >>> ghc-steering-committee at haskell.org >>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>> > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -------------- next part -------------- An HTML attachment was scrubbed... URL: From chak at justtesting.org Thu Oct 19 01:08:56 2017 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Thu, 19 Oct 2017 12:08:56 +1100 Subject: [ghc-steering-committee] Proposal: Type Fixity (#65), Consensus: accept, own language extension? In-Reply-To: <0D402BA4-93C4-45C9-B35C-C4516C5B6304@cs.brynmawr.edu> References: <1503857788.4643.2.camel@joachim-breitner.de> <1505924631.5913.14.camel@joachim-breitner.de> <1507400762.25530.5.camel@joachim-breitner.de> <1ADEFDFB-BC0F-42E5-AC9D-3A1BF14D1474@justtesting.org> <18ACF281-CC23-4845-99B3-205CF2CC7768@cs.brynmawr.edu> <6F338105-BCD2-4006-BAF0-C786ADCEDA90@gmail.com> <5445BC95-9DAC-4CF2-909F-910814D7C467@cs.brynmawr.edu> <1508359779.9354.12.camel@joachim-breitner.de> <0D402BA4-93C4-45C9-B35C-C4516C5B6304@cs.brynmawr.edu> Message-ID: <72484F62-DC04-43A3-910A-26E573794FD0@justtesting.org> If I may summarise the last few messages on this thread, it seems to me that, so far, everybody agrees that it would be beneficial to have two or more categories of extensions that come with different expectations of stability. (Whether that is by marking them as stable or annotating them with versions or years are details we will figure out.) Richard, I do understand your fear about not being able to move quickly, and I think, we all want to preserve that property of Haskell. However, I would like us to think about how we can preserve agility, while providing sufficient stability. (I know that is hard, but easy problems are boring, so let’s rise to the challenge.) As I said, in my previous message, I consider Haskell Prime to be dead (for all practical purposes). There will be no more Haskell standard. The closest thing to a Haskell standards committee —namely, the ”GHC Haskell” standards committee— is this group! The plan with LANGUAGE extensions was that they do migrate into the standard when they are stable. This is no longer going to happen. Hence, *we* owe it to GHC’s users to make that determination on an extension by extension basis and enforce it through the proposals process. Now, we can discuss the details: * What categories are there? * How long do extensions remain agile? * How do we make the determination when to promote an extension to a more stable category? Before we get too tied up in the details, I would like to discuss two higher-order points: * Do we all agree that we need categories of stabilities for extensions (for the reasons outlined above)? * Can we agree that we cannot leave it solely to extension authors to assign stabilities? (In particular, we already have lots of extensions and we need to take care of those.) Why not leave it to extension authors? They have no (direct) interest in stability. We are the gate keepers. It is our job. Cheers, Manuel PS: There is also the issue of libraries, but that is really the responsibilities of the Core Libraries Committee (and maybe we have to have a chat with them). PPS: This is also very much a beginner issue. Experts know from experience which extensions are stable. Newcomers often ask, what can I safely use? It’s not spelled out anywhere. (Ping Chris.) > Richard Eisenberg : >> On Oct 18, 2017, at 4:49 PM, Joachim Breitner wrote: >> >> The way out there might be to try our best, and if we get it wrong and >> mark an extension as stable too early, we’ll just have to add a new >> pragma for the improved ones… so that seems like a good compromise. >> > > Yes, this is exactly what I was thinking. For example, TypeFamilies might have been marked as stable before closed type families came about... but then we would just have -XClosedTypeFamilies -- not so horrible. > >> The other failure mode would be that we will have _too strict_ >> requirements for marking extensions as stable, so that production code >> will inevitably have to use non-stable extensions, and not much is >> gained. > > This, too, is exactly what I was thinking. Industrial users and book authors have the most to gain from an extension being marked as stable. I would expect that proposals would come from these groups marking extensions as stable, and then we could have a debate. > > Richard > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From rae at cs.brynmawr.edu Thu Oct 19 01:48:29 2017 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Wed, 18 Oct 2017 21:48:29 -0400 Subject: [ghc-steering-committee] Proposal: Type Fixity (#65), Consensus: accept, own language extension? In-Reply-To: <72484F62-DC04-43A3-910A-26E573794FD0@justtesting.org> References: <1503857788.4643.2.camel@joachim-breitner.de> <1505924631.5913.14.camel@joachim-breitner.de> <1507400762.25530.5.camel@joachim-breitner.de> <1ADEFDFB-BC0F-42E5-AC9D-3A1BF14D1474@justtesting.org> <18ACF281-CC23-4845-99B3-205CF2CC7768@cs.brynmawr.edu> <6F338105-BCD2-4006-BAF0-C786ADCEDA90@gmail.com> <5445BC95-9DAC-4CF2-909F-910814D7C467@cs.brynmawr.edu> <1508359779.9354.12.camel@joachim-breitner.de> <0D402BA4-93C4-45C9-B35C-C4516C5B6304@cs.brynmawr.edu> <72484F62-DC04-43A3-910A-26E573794FD0@justtesting.org> Message-ID: Manuel, I agree with everything you've just said. Thanks for articulating it so clearly. > On Oct 18, 2017, at 9:08 PM, Manuel M T Chakravarty wrote: > > If I may summarise the last few messages on this thread, it seems to me that, so far, everybody agrees that it would be beneficial to have two or more categories of extensions that come with different expectations of stability. (Whether that is by marking them as stable or annotating them with versions or years are details we will figure out.) > > Richard, I do understand your fear about not being able to move quickly, and I think, we all want to preserve that property of Haskell. However, I would like us to think about how we can preserve agility, while providing sufficient stability. (I know that is hard, but easy problems are boring, so let’s rise to the challenge.) > > As I said, in my previous message, I consider Haskell Prime to be dead (for all practical purposes). There will be no more Haskell standard. The closest thing to a Haskell standards committee —namely, the ”GHC Haskell” standards committee— is this group! > > The plan with LANGUAGE extensions was that they do migrate into the standard when they are stable. This is no longer going to happen. Hence, *we* owe it to GHC’s users to make that determination on an extension by extension basis and enforce it through the proposals process. > > Now, we can discuss the details: > > * What categories are there? > * How long do extensions remain agile? > * How do we make the determination when to promote an extension to a more stable category? > > Before we get too tied up in the details, I would like to discuss two higher-order points: > > * Do we all agree that we need categories of stabilities for extensions (for the reasons outlined above)? > * Can we agree that we cannot leave it solely to extension authors to assign stabilities? (In particular, we already have lots of extensions and we need to take care of those.) > > Why not leave it to extension authors? They have no (direct) interest in stability. We are the gate keepers. It is our job. > > Cheers, > Manuel > > PS: There is also the issue of libraries, but that is really the responsibilities of the Core Libraries Committee (and maybe we have to have a chat with them). > > PPS: This is also very much a beginner issue. Experts know from experience which extensions are stable. Newcomers often ask, what can I safely use? It’s not spelled out anywhere. (Ping Chris.) > >> Richard Eisenberg : >>> On Oct 18, 2017, at 4:49 PM, Joachim Breitner wrote: >>> >>> The way out there might be to try our best, and if we get it wrong and >>> mark an extension as stable too early, we’ll just have to add a new >>> pragma for the improved ones… so that seems like a good compromise. >>> >> >> Yes, this is exactly what I was thinking. For example, TypeFamilies might have been marked as stable before closed type families came about... but then we would just have -XClosedTypeFamilies -- not so horrible. >> >>> The other failure mode would be that we will have _too strict_ >>> requirements for marking extensions as stable, so that production code >>> will inevitably have to use non-stable extensions, and not much is >>> gained. >> >> This, too, is exactly what I was thinking. Industrial users and book authors have the most to gain from an extension being marked as stable. I would expect that proposals would come from these groups marking extensions as stable, and then we could have a debate. >> >> Richard >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > From simonpj at microsoft.com Thu Oct 19 08:23:42 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 19 Oct 2017 08:23:42 +0000 Subject: [ghc-steering-committee] Proposal: Type Fixity (#65), Consensus: accept, own language extension? In-Reply-To: <72484F62-DC04-43A3-910A-26E573794FD0@justtesting.org> References: <1503857788.4643.2.camel@joachim-breitner.de> <1505924631.5913.14.camel@joachim-breitner.de> <1507400762.25530.5.camel@joachim-breitner.de> <1ADEFDFB-BC0F-42E5-AC9D-3A1BF14D1474@justtesting.org> <18ACF281-CC23-4845-99B3-205CF2CC7768@cs.brynmawr.edu> <6F338105-BCD2-4006-BAF0-C786ADCEDA90@gmail.com> <5445BC95-9DAC-4CF2-909F-910814D7C467@cs.brynmawr.edu> <1508359779.9354.12.camel@joachim-breitner.de> <0D402BA4-93C4-45C9-B35C-C4516C5B6304@cs.brynmawr.edu> <72484F62-DC04-43A3-910A-26E573794FD0@justtesting.org> Message-ID: | If I may summarise the last few messages on this thread, it seems to | me that, so far, everybody agrees that it would be beneficial to have | two or more categories of extensions that come with different | expectations of stability. I'm much happier with this than with -XStaticPointers1 -XStaticPointers2 etc. Once we had such categories, we could use the GHC proposals process itself to allow people to propose moving a flag from 'experimental' to 'stable' or whatever. Simon | -----Original Message----- | From: ghc-steering-committee [mailto:ghc-steering-committee- | bounces at haskell.org] On Behalf Of Manuel M T Chakravarty | Sent: 19 October 2017 02:09 | To: Richard Eisenberg | Cc: ghc-steering-committee at haskell.org; Joachim Breitner | | Subject: Re: [ghc-steering-committee] Proposal: Type Fixity (#65), | Consensus: accept, own language extension? | | If I may summarise the last few messages on this thread, it seems to | me that, so far, everybody agrees that it would be beneficial to have | two or more categories of extensions that come with different | expectations of stability. (Whether that is by marking them as stable | or annotating them with versions or years are details we will figure | out.) | | Richard, I do understand your fear about not being able to move | quickly, and I think, we all want to preserve that property of | Haskell. However, I would like us to think about how we can preserve | agility, while providing sufficient stability. (I know that is hard, | but easy problems are boring, so let’s rise to the challenge.) | | As I said, in my previous message, I consider Haskell Prime to be dead | (for all practical purposes). There will be no more Haskell standard. | The closest thing to a Haskell standards committee —namely, the ”GHC | Haskell” standards committee— is this group! | | The plan with LANGUAGE extensions was that they do migrate into the | standard when they are stable. This is no longer going to happen. | Hence, *we* owe it to GHC’s users to make that determination on an | extension by extension basis and enforce it through the proposals | process. | | Now, we can discuss the details: | | * What categories are there? | * How long do extensions remain agile? | * How do we make the determination when to promote an extension to a | more stable category? | | Before we get too tied up in the details, I would like to discuss two | higher-order points: | | * Do we all agree that we need categories of stabilities for | extensions (for the reasons outlined above)? | * Can we agree that we cannot leave it solely to extension authors to | assign stabilities? (In particular, we already have lots of extensions | and we need to take care of those.) | | Why not leave it to extension authors? They have no (direct) interest | in stability. We are the gate keepers. It is our job. | | Cheers, | Manuel | | PS: There is also the issue of libraries, but that is really the | responsibilities of the Core Libraries Committee (and maybe we have to | have a chat with them). | | PPS: This is also very much a beginner issue. Experts know from | experience which extensions are stable. Newcomers often ask, what can | I safely use? It’s not spelled out anywhere. (Ping Chris.) | | > Richard Eisenberg : | >> On Oct 18, 2017, at 4:49 PM, Joachim Breitner wrote: | >> | >> The way out there might be to try our best, and if we get it wrong | >> and mark an extension as stable too early, we’ll just have to add a | >> new pragma for the improved ones… so that seems like a good | compromise. | >> | > | > Yes, this is exactly what I was thinking. For example, TypeFamilies | might have been marked as stable before closed type families came | about... but then we would just have -XClosedTypeFamilies -- not so | horrible. | > | >> The other failure mode would be that we will have _too strict_ | >> requirements for marking extensions as stable, so that production | >> code will inevitably have to use non-stable extensions, and not | much | >> is gained. | > | > This, too, is exactly what I was thinking. Industrial users and book | authors have the most to gain from an extension being marked as | stable. I would expect that proposals would come from these groups | marking extensions as stable, and then we could have a debate. | > | > Richard | > _______________________________________________ | > ghc-steering-committee mailing list | > ghc-steering-committee at haskell.org | > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- | committ | > ee | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee at haskell.org | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- | committee From mail at joachim-breitner.de Thu Oct 19 14:19:24 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 19 Oct 2017 10:19:24 -0400 Subject: [ghc-steering-committee] Proposal: Type Fixity (#65), Recommendation: accept under ExplicitNamespaces Message-ID: <1508422764.978.6.camel@joachim-breitner.de> Hi committee, the other thread on this proposal has veered off into a (very useful) meta-discussion. It seems that we will likely soon have a way to bless certain language extensions as stable, but this implies that ExplicitNamespaces it not (yet) one of those. In this light, I want to make progress on the proposal at hand, so I propose that we accept the proposal https://github.com/ghc-proposals/ghc-proposals/pull/65 including the extension to WARNING pragmas etc. in https://github.com/ghc-proposals/ghc-proposals/pull/65#issuecomment-334973450 (which I will ask Ryan Scott to incorporate into the proposal) and under the agenda of expanding (completing) ExplicitNamespaces, rather than introducing a separate language extension. Is that fine with everyone? As always, I will take silence as a yes, and declare victory^Hconsensus after a week or so. Greetings, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From mail at joachim-breitner.de Thu Oct 19 14:54:10 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 19 Oct 2017 10:54:10 -0400 Subject: [ghc-steering-committee] Stable Language extension discussion In-Reply-To: References: <1503857788.4643.2.camel@joachim-breitner.de> <1505924631.5913.14.camel@joachim-breitner.de> <1507400762.25530.5.camel@joachim-breitner.de> <1ADEFDFB-BC0F-42E5-AC9D-3A1BF14D1474@justtesting.org> <18ACF281-CC23-4845-99B3-205CF2CC7768@cs.brynmawr.edu> <6F338105-BCD2-4006-BAF0-C786ADCEDA90@gmail.com> <5445BC95-9DAC-4CF2-909F-910814D7C467@cs.brynmawr.edu> <1508359779.9354.12.camel@joachim-breitner.de> <0D402BA4-93C4-45C9-B35C-C4516C5B6304@cs.brynmawr.edu> <72484F62-DC04-43A3-910A-26E573794FD0@justtesting.org> Message-ID: <1508424850.978.9.camel@joachim-breitner.de> Hi, there are some good ideas here, and I sense some common agreements, but let’s move this discussion to GitHub. I hew out a rough draft of what I think we have in mind in the form of a proposal, and we can discuss it here: https://github.com/ghc-proposals/ghc-proposals/pull/85 Also, feel free to consider this a collaborative editing process and edit the file https://github.com/ghc-proposals/ghc-proposals/blob/stable-extensions/new-proposal.rst directly (it lives on a branch) Greetings, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From cma at bitemyapp.com Fri Oct 20 00:59:34 2017 From: cma at bitemyapp.com (Christopher Allen) Date: Thu, 19 Oct 2017 19:59:34 -0500 Subject: [ghc-steering-committee] Proposal: Type Fixity (#65), Consensus: accept, own language extension? In-Reply-To: <72484F62-DC04-43A3-910A-26E573794FD0@justtesting.org> References: <1503857788.4643.2.camel@joachim-breitner.de> <1505924631.5913.14.camel@joachim-breitner.de> <1507400762.25530.5.camel@joachim-breitner.de> <1ADEFDFB-BC0F-42E5-AC9D-3A1BF14D1474@justtesting.org> <18ACF281-CC23-4845-99B3-205CF2CC7768@cs.brynmawr.edu> <6F338105-BCD2-4006-BAF0-C786ADCEDA90@gmail.com> <5445BC95-9DAC-4CF2-909F-910814D7C467@cs.brynmawr.edu> <1508359779.9354.12.camel@joachim-breitner.de> <0D402BA4-93C4-45C9-B35C-C4516C5B6304@cs.brynmawr.edu> <72484F62-DC04-43A3-910A-26E573794FD0@justtesting.org> Message-ID: >The plan with LANGUAGE extensions was that they do migrate into the standard when they are stable. This is no longer going to happen. Hence, *we* owe it to GHC’s users to make that determination on an extension by extension basis and enforce it through the proposals process. I agree. >Now, we can discuss the details: >* What categories are there? >* How long do extensions remain agile? >* How do we make the determination when to promote an extension to a more stable category? My suggestion would be to keep the categories minimal and focused on the way they function in the compiler-as-user-interface: - Must be manually enabled. We can (should?) accompany unstable or potentially unsafe extensions with warnings describing those caveats, but I don't think building an ontology of stableness would be productive. - Must be manually disabled. I would love to nominate ScopedTypeVariables for this but I'm sure there are caveats to STV I haven't yet encountered. This status implies the extension is a candidate for eventual incorporation. - Incorporated. Cannot be disabled in GHC Haskell, considered part of the language (standard?) proper now. If you wanted to extend an extension in the defaulted state, you would create a new extension and it starts at the first stage. The new extension modifying an existing feature must prove itself to be stable and worthwhile of defaulting or later incorporation independently of the feature it modified. >* Can we agree that we cannot leave it solely to extension authors to assign stabilities? (In particular, we already have lots of extensions and we need to take care of those.) >Why not leave it to extension authors? They have no (direct) interest in stability. We are the gate keepers. It is our job. I agree with this, extension authors cannot be solely responsible for ascertaining how stable something is or where it is on the path to becoming defaulted or incorporated. >PPS: This is also very much a beginner issue. Experts know from experience which extensions are stable. Newcomers often ask, what can I safely use? It’s not spelled out anywhere. (Ping Chris.) There are three main areas where the extensions issue tends to rankle me: 1. As a working user of Haskell that touches a lot of libraries, does a lot of throw-away projects as experiments, I've had to start using hpack (http://hackage.haskell.org/package/hpack) to generate my Cabal files. Some of the motivation for that has been to have a single global list of default-extensions that apply to all of the project's build/test/bench target stanzas. I do this often enough that I copy and paste the default-extensions list between projects not even bothering to weed out the unnecessary ones on the assumption I'll need them eventually anyway. This might seem careless but I toss up a lot of experiments, tutorials, and demonstrations and I don't want to keep having to restart my REPL session because I forgot something. Example of my copied-and-pasted default-extensions: default-extensions: - ConstraintKinds - DataKinds - DeriveFunctor - DeriveGeneric - FlexibleContexts - FlexibleInstances - FunctionalDependencies - GADTs - ImplicitParams - LambdaCase - MultiParamTypeClasses - OverloadedStrings - PartialTypeSignatures - QuasiQuotes - RankNTypes - RecordWildCards - TemplateHaskell - TypeFamilies - TypeOperators - ScopedTypeVariables - UndecidableInstances I realize not all of these are benign. I'll cross that bridge when it someday bites me after over 5 years of using Haskell. I think the only nasty/dead-end ones I've run into have been incoherent instances (Hail Oleg) and impredicative types. Which I hear could be fixed maybe? That'd be neat. FWIW, SafeHaskell is not representative of what's considered "safe" for GHC extensions among the Haskell users I talk to. Different understanding/standard of "safe", possibly partly because we don't have reproducible builds anyway? Stephen Diehl's Haskell tutorial is the usual citation for what extensions are benign/potentially dangerous: http://dev.stephendiehl.com/hask/#the-benign 2. Extensions get weaponized in PL polemics as incontrovertible proof of how "complicated" GHC Haskell is or how much Haskell "needs" before it's a complete language. I admit this isn't strictly within our remit but it is very tiresome. 3. #2 then leads to: new people terrified of turning on an extension even when it's benign and exactly what they want to do at that particular moment. Even in cases where GHC is telling them to do it. Related to new-people-fear is new users believing extensions must be hopelessly complicated if they extend an already seemingly difficult-to-learn language. I don't think we'll ever be totally rid of extensions and I'm not sure it'd be a good thing if we were. If we could make extension-spam the exception rather than the rule on the non-libraries I work on I think that would be a tremendous improvement to peoples' perception of complexity and difficulty. And to be clear, I think it's mostly perception. I've been able to teach RankNTypes to otherwise new Haskell users quite successfully in the past, with the main prerequisites being a sound understanding of polymorphism and variable binding. Thank you Manuel, this is great. On Wed, Oct 18, 2017 at 8:08 PM, Manuel M T Chakravarty wrote: > If I may summarise the last few messages on this thread, it seems to me that, so far, everybody agrees that it would be beneficial to have two or more categories of extensions that come with different expectations of stability. (Whether that is by marking them as stable or annotating them with versions or years are details we will figure out.) > > Richard, I do understand your fear about not being able to move quickly, and I think, we all want to preserve that property of Haskell. However, I would like us to think about how we can preserve agility, while providing sufficient stability. (I know that is hard, but easy problems are boring, so let’s rise to the challenge.) > > As I said, in my previous message, I consider Haskell Prime to be dead (for all practical purposes). There will be no more Haskell standard. The closest thing to a Haskell standards committee —namely, the ”GHC Haskell” standards committee— is this group! > > The plan with LANGUAGE extensions was that they do migrate into the standard when they are stable. This is no longer going to happen. Hence, *we* owe it to GHC’s users to make that determination on an extension by extension basis and enforce it through the proposals process. > > Now, we can discuss the details: > > * What categories are there? > * How long do extensions remain agile? > * How do we make the determination when to promote an extension to a more stable category? > > Before we get too tied up in the details, I would like to discuss two higher-order points: > > * Do we all agree that we need categories of stabilities for extensions (for the reasons outlined above)? > * Can we agree that we cannot leave it solely to extension authors to assign stabilities? (In particular, we already have lots of extensions and we need to take care of those.) > > Why not leave it to extension authors? They have no (direct) interest in stability. We are the gate keepers. It is our job. > > Cheers, > Manuel > > PS: There is also the issue of libraries, but that is really the responsibilities of the Core Libraries Committee (and maybe we have to have a chat with them). > > PPS: This is also very much a beginner issue. Experts know from experience which extensions are stable. Newcomers often ask, what can I safely use? It’s not spelled out anywhere. (Ping Chris.) > >> Richard Eisenberg : >>> On Oct 18, 2017, at 4:49 PM, Joachim Breitner wrote: >>> >>> The way out there might be to try our best, and if we get it wrong and >>> mark an extension as stable too early, we’ll just have to add a new >>> pragma for the improved ones… so that seems like a good compromise. >>> >> >> Yes, this is exactly what I was thinking. For example, TypeFamilies might have been marked as stable before closed type families came about... but then we would just have -XClosedTypeFamilies -- not so horrible. >> >>> The other failure mode would be that we will have _too strict_ >>> requirements for marking extensions as stable, so that production code >>> will inevitably have to use non-stable extensions, and not much is >>> gained. >> >> This, too, is exactly what I was thinking. Industrial users and book authors have the most to gain from an extension being marked as stable. I would expect that proposals would come from these groups marking extensions as stable, and then we could have a debate. >> >> Richard >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Chris Allen Currently working on http://haskellbook.com From cma at bitemyapp.com Mon Oct 23 03:47:36 2017 From: cma at bitemyapp.com (Christopher Allen) Date: Sun, 22 Oct 2017 22:47:36 -0500 Subject: [ghc-steering-committee] GHC steering committee participation In-Reply-To: <87y3xgd102.fsf@ben-laptop.smart-cactus.org> References: <5C93D9A3-08D1-43B6-AE54-4AA457E59897@gmail.com> <8EDFDD90-942B-4CDB-9407-8CF536BBA843@gmail.com> <1486155334.847.1.camel@joachim-breitner.de> <87y3xgd102.fsf@ben-laptop.smart-cactus.org> Message-ID: So that community members understand what happened, I believe this wiki page should be updated to reflect the change in committee membership: https://ghc.haskell.org/trac/ghc/wiki/SteeringCommittee On Wed, Feb 8, 2017 at 11:51 AM, Ben Gamari wrote: > Simon Peyton Jones writes: > >> Simon and I discussed this, and while we see merit in Joachim's point, >> we're happy to just replacing Adze with Roman forthwith, for the >> reasons Manual sets out below. >> >> Life is short -- we should concentrate on progressing proposals rather >> than more nomination cycles. There'll be time for that later! >> >> OK? Let's just go for it. >> > Yes, I can see the argument for this. Given how stretched we all are > already, I suppose this is the pragmatic way forward. No objection here. > > Cheers, > > - Ben > > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -- Chris Allen Currently working on http://haskellbook.com From mail at joachim-breitner.de Mon Oct 23 03:49:57 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sun, 22 Oct 2017 23:49:57 -0400 Subject: [ghc-steering-committee] GHC steering committee participation In-Reply-To: References: <5C93D9A3-08D1-43B6-AE54-4AA457E59897@gmail.com> <8EDFDD90-942B-4CDB-9407-8CF536BBA843@gmail.com> <1486155334.847.1.camel@joachim-breitner.de> <87y3xgd102.fsf@ben-laptop.smart-cactus.org> Message-ID: <1508730597.6650.19.camel@joachim-breitner.de> Hi, well spotted and fixed. Joachim Am Sonntag, den 22.10.2017, 22:47 -0500 schrieb Christopher Allen: > So that community members understand what happened, I believe this > wiki page should be updated to reflect the change in committee > membership: > > https://ghc.haskell.org/trac/ghc/wiki/SteeringCommittee > > > On Wed, Feb 8, 2017 at 11:51 AM, Ben Gamari wrote: > > Simon Peyton Jones writes: > > > > > Simon and I discussed this, and while we see merit in Joachim's point, > > > we're happy to just replacing Adze with Roman forthwith, for the > > > reasons Manual sets out below. > > > > > > Life is short -- we should concentrate on progressing proposals rather > > > than more nomination cycles. There'll be time for that later! > > > > > > OK? Let's just go for it. > > > > > > > Yes, I can see the argument for this. Given how stretched we all are > > already, I suppose this is the pragmatic way forward. No objection here. > > > > Cheers, > > > > - Ben > > > > > > _______________________________________________ > > ghc-steering-committee mailing list > > ghc-steering-committee at haskell.org > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > > > > -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From cma at bitemyapp.com Mon Oct 23 03:52:16 2017 From: cma at bitemyapp.com (Christopher Allen) Date: Sun, 22 Oct 2017 22:52:16 -0500 Subject: [ghc-steering-committee] GHC steering committee participation In-Reply-To: <1508730597.6650.19.camel@joachim-breitner.de> References: <5C93D9A3-08D1-43B6-AE54-4AA457E59897@gmail.com> <8EDFDD90-942B-4CDB-9407-8CF536BBA843@gmail.com> <1486155334.847.1.camel@joachim-breitner.de> <87y3xgd102.fsf@ben-laptop.smart-cactus.org> <1508730597.6650.19.camel@joachim-breitner.de> Message-ID: Thank you for the rapid (and permanent, since you deduplicated the information) fix! On Sun, Oct 22, 2017 at 10:49 PM, Joachim Breitner wrote: > Hi, > > well spotted and fixed. > > Joachim > > Am Sonntag, den 22.10.2017, 22:47 -0500 schrieb Christopher Allen: >> So that community members understand what happened, I believe this >> wiki page should be updated to reflect the change in committee >> membership: >> >> https://ghc.haskell.org/trac/ghc/wiki/SteeringCommittee >> >> >> On Wed, Feb 8, 2017 at 11:51 AM, Ben Gamari wrote: >> > Simon Peyton Jones writes: >> > >> > > Simon and I discussed this, and while we see merit in Joachim's point, >> > > we're happy to just replacing Adze with Roman forthwith, for the >> > > reasons Manual sets out below. >> > > >> > > Life is short -- we should concentrate on progressing proposals rather >> > > than more nomination cycles. There'll be time for that later! >> > > >> > > OK? Let's just go for it. >> > > >> > >> > Yes, I can see the argument for this. Given how stretched we all are >> > already, I suppose this is the pragmatic way forward. No objection here. >> > >> > Cheers, >> > >> > - Ben >> > >> > >> > _______________________________________________ >> > ghc-steering-committee mailing list >> > ghc-steering-committee at haskell.org >> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> > >> >> >> > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -- Chris Allen Currently working on http://haskellbook.com