<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Mathieu asked me to relay this message to the committee.<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">Forwarded message</div><br class="Apple-interchange-newline"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;" class=""><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif; color:rgba(0, 0, 0, 1.0);" class=""><b class="">From: </b></span><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif;" class="">"Boespflug, Mathieu" <<a href="mailto:m@tweag.io" class="">m@tweag.io</a>><br class=""></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;" class=""><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif; color:rgba(0, 0, 0, 1.0);" class=""><b class="">Subject: </b></span><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif;" class=""><b class="">Re: [ghc-steering-committee] Proposal: Type Fixity (#65), Consensus: accept, own language extension?</b><br class=""></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;" class=""><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif; color:rgba(0, 0, 0, 1.0);" class=""><b class="">Date: </b></span><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif;" class="">18. Oktober 2017 um 21:34:12 GMT+11<br class=""></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;" class=""><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif; color:rgba(0, 0, 0, 1.0);" class=""><b class="">To: </b></span><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif;" class="">Manuel M T Chakravarty <<a href="mailto:chak@justtesting.org" class="">chak@justtesting.org</a>><br class=""></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;" class=""><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif; color:rgba(0, 0, 0, 1.0);" class=""><b class="">Cc: </b></span><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif;" class="">Facundo Domínguez <<a href="mailto:facundo.dominguez@tweag.io" class="">facundo.dominguez@tweag.io</a>><br class=""></span></div><br class=""><div class=""><div class="">Hi Manuel,<br class=""><br class="">don't know if I'm allowed to post to this mailing list. So would<br class="">appreciate if you could forward the following experience report.<br class=""><br class="">Facundo and I worked on the -XStaticPointers extension. It has gone<br class="">through various improvements/generalizations for each new GHC release.<br class="">Eg originally, (static e) evaluated to something of type StaticPtr a,<br class="">whereas now it has type IsStatic s => s a, to allow for overloading<br class="">(static e) literals similarly to string literals. A corresponding<br class="">change was made to base. In the future there might be other changes,<br class="">in particular to finally make pointer lookup type safe (it's not,<br class="">currently), or to generalize IsStatic to a multi-param type class<br class="">(based on real-world experience). Should we have -XStaticPointers1,<br class="">-XStaticPointers2, etc for each new variant of this extension any time<br class="">we make any improvement to it (which have all been backwards<br class="">compatible so far)? That would be pretty onerous.<br class=""><br class="">Now, -XStaticPointers was added as an "experimental" extension, and so<br class="">in a strong sense we still have license to make all manner of changes<br class="">to that extension. But aren't they all? Isn't the very reason for<br class="">adding things as extensions first (rather than as part of the base<br class="">language) so that we can introduce new ideas and experiment with them<br class="">in the wild? And if the extension passes the test of widespread<br class="">usefulness then we etch in one of the Haskell Report stone tablets?<br class=""><br class="">Writing modern Haskell already entails a fair amount of bureaucracy<br class="">(among which language extension bureaucracy). Many different<br class="">variations of the same basic extension may well add to that<br class="">bureaucracy a fair bit. And what's more, be intimidating to beginners.<br class=""><br class="">Best,<br class="">--<br class="">Mathieu Boespflug<br class="">Founder at <a href="http://tweag.io" class="">http://tweag.io</a>.<br class=""><br class=""><br class="">On 17 October 2017 at 12:30, Manuel M T Chakravarty<br class=""><<a href="mailto:chak@justtesting.org" class="">chak@justtesting.org</a>> wrote:<br class=""><blockquote type="cite" class="">I completely agree with Simon: this is an important question.<br class=""><br class="">I think, it would be good to have at least (1), but better (2).<br class=""><br class="">Why? Because Haskell’ really doesn’t get anywhere and in its absence the<br class="">guarantees provided by GHC are the only language stability there is. Maybe<br class="">it is unfair to put this burden on the compiler, instead of on a separate<br class="">language specification, but that is how it is.<br class=""><br class="">Now, I reckon the main obstacle to (1) and (2) is that LANGUAGE extensions,<br class="">when they appear first, are in flux, because they are often parts of<br class="">experiments. Hence, I’d like to suggest that we might be able to lessen the<br class="">tension between experimentation and stability by formally associating a<br class="">”stability” of one of ”alpha”, ”beta”, or ”stable” with each extension.<br class=""><br class="">As we all know, these stability annotations don’t work at all on Hackage as<br class="">nobody ever moves their packages away from ”experimental”. Hence, I suggest<br class="">that we do not make this the choice of the person who proposes an extension,<br class="">but part of our process. There are a few options, which might be worth<br class="">considering.<br class=""><br class="">For example, when a LANGUAGE extension is first proposed, it starts at<br class="">”alpha”. When latter a proposal is submitted to amend the extension, that<br class="">amendment is approved by us only if it successfully argues that it improves<br class="">the maturity of the extension such that it warrants ”beta” stability. And<br class="">then, the same with ”stable” on the second amendment. Finally, ”stable”<br class="">language extensions cannot be changed unless it is to fix a grave semantic<br class="">error or similar.<br class=""><br class="">Instead (or in addition) of bumping stability on every new proposal<br class="">involving the extension, we could also adopt a time (or release) based<br class="">scheme.<br class=""><br class="">Cheers,<br class="">Manuel<br class=""><br class="">PS: BTW, we are pushing for getting to 6 monthly release of GHC. This means<br class="">that without any guarantees across versions, we would potentially increase<br class="">variability, which would be bad.<br class=""><br class="">Simon Marlow <<a href="mailto:marlowsd@gmail.com" class="">marlowsd@gmail.com</a>>:<br class=""><br class="">The main reason I took a position on the issue of extension flags is to<br class="">force the question: what should LANGUAGE mean? I think it's important to<br class="">resolve this, to inform future decisions. Here are some options:<br class=""><br class="">1. LANGUAGE fully specifies the grammar of the source file<br class="">2. LANGUAGE fully specifies the grammar and semantics of the source file<br class="">3. LANGUAGE tells the compiler what extensions are required, but otherwise<br class="">provides no guarantees. The source file might not compile with a given<br class="">version of GHC even if it supports all the extensions listed. In other<br class="">words, LANGUAGE together with a GHC version range specifies the grammar and<br class="">semantics of the source file.<br class=""><br class="">I think what we have right now is 3, because we change the meaning of<br class="">extensions from version to version of GHC. There are advantages to 1 and 2:<br class="">for example, if we had 1, then we could parse all of Hackage with<br class="">haskell-src-exts (or at least identify the subset of source files that can<br class="">be parsed via their LANGUAGE pragmas). If we had 2, then we could parse,<br class="">rename and typecheck all of Hackage using haskell-src-exts, haskel-names,<br class="">and haskell-type-exts.<br class=""><br class="">Perhaps we want to say that we can only *add* syntax to an existing<br class="">extension, not change or remove it. This is a variant of 3 that requires<br class="">only a lower bound on the GHC version required, not an upper bound, and it<br class="">provides some of the benefits of 1 and 2: you just need a sufficiently<br class="">recent version of haskell-src-exts et. al.<br class=""><br class="">Anyway, I mainly wanted to ensure that we're clear about what LANGUAGE<br class="">means. If we believe the implications of 1 and 2 are too onerous (never<br class="">changing extensions), so what we want is 3, so be it.<br class=""><br class="">Cheers<br class="">Simon<br class=""><br class=""><br class="">On 10 October 2017 at 03:54, Iavor Diatchki <<a href="mailto:iavor.diatchki@gmail.com" class="">iavor.diatchki@gmail.com</a>><br class="">wrote:<br class=""><blockquote type="cite" class=""><br class=""><br class=""><br class=""><br class="">Hello,<br class=""><br class="">my preference would be to add this to one of the existing extensions<br class="">(either "explicit namespaces", or "type level operators").<br class=""><br class="">Iavor<br class=""><br class=""><br class=""><br class=""><br class=""><br class="">On Sat, Oct 7, 2017 at 11:26 AM Joachim Breitner<br class=""><<a href="mailto:mail@joachim-breitner.de" class="">mail@joachim-breitner.de</a>> wrote:<br class=""><blockquote type="cite" class=""><br class="">Hi Committee,<br class=""><br class="">the discussion has ebbed down again. I observe that a clear majority is<br class="">in favor. I don’t think there is a need for a formal vote, so I will<br class="">proceed with this decision.<br class=""><br class="">Simon M brought up the next issue: Shall we require a separate language<br class="">extension for this, or can it go under the hood of<br class="">`ExplicitNamespaces`?<br class=""><br class="">So far Simon M expressed a strong preference for the former, while I am<br class=""> inclined to prefer the latter, and would like to hear a few more<br class="">opinions on this detail (which certainly would set precedence for<br class="">future decisions).<br class=""><br class="">Richard brought up the idea of versioned language extensions; that idea<br class="">can certainly be investigated, but better independently. We have to<br class="">deal with this proposal with the tools we have.<br class=""><br class="">Greetings,<br class="">Joachim<br class=""><br class=""><br class="">Am Mittwoch, den 20.09.2017, 12:23 -0400 schrieb Joachim Breitner:<br class=""><blockquote type="cite" class="">Hi,<br class=""><br class="">the type fixity proposal<br class="">(<a href="https://github.com/ghc-proposals/ghc-proposals/pull/65" class="">https://github.com/ghc-proposals/ghc-proposals/pull/65</a>)<br class="">was met with mixed reactions.<br class=""><br class=""> * I recommended rejection and Manuel strongly agrees with me.<br class=""> * SPJ does not have strong opinions either way.<br class=""> * Richard is in favor, and Iavor agrees.<br class=""><br class=""><br class="">Our process says “If consensus is elusive, then we vote, with the<br class="">Simons retaining veto power.” It looks like this might be such a case.<br class="">Should we go ahead and vote, or is more discussion likely to sway some<br class="">of us?<br class=""><br class="">(I guess I can be swayed towards acceptance, especially if this<br class="">proposal re-uses existing syntactic idioms from export lists with<br class="">ExplicitNamespaces on.)<br class=""><br class="">Greetings,<br class="">Joachim<br class=""><br class=""><br class=""><br class="">Am Sonntag, den 27.08.2017, 20:16 +0200 schrieb Joachim Breitner:<br class=""><blockquote type="cite" class="">Dear Committee,<br class=""><br class="">Ryan Scott’s proposal to allow fixity declaration to explicitly<br class="">target<br class="">values or types has been brought before us:<br class=""><br class=""><a href="https://github.com/RyanGlScott/ghc-proposals/blob/type-infix/0000-type-infix.rst" class="">https://github.com/RyanGlScott/ghc-proposals/blob/type-infix/0000-type-infix.rst</a><br class="">https://github.com/ghc-proposals/ghc-proposals/pull/65<br class=""><br class="">I (the secretary) nominates myself as the shepherd, so I can right<br class="">away<br class="">continue giving a recommendation.<br class=""><br class="">I propose to reject this proposal. The main reasons are:<br class=""> * it is not clear if there is a real use case for this. Has anyone<br class=""> ever complained about the status quo?<br class=""> The proposal does not motivate the need for a change well enough.<br class=""> (There is a related bug in TH, but that bug can probably simply be<br class=""> fixed.)<br class=""> * The status quo can be sold as a feature, rather than a<br class="">short-coming.<br class=""> Namely that an operator has a fixed fixity, no matter what<br class="">namespace<br class=""> it lives in.<br class=""> This matches morally what other languages do: In Gallina, fixity<br class=""> is assigned to names independent of their definition, AFAIK.<br class=""> * There is a non-trivial implementation and education overhead, a<br class=""> weight that is not pulled by the gains.<br class=""><br class="">If we’d design Haskell from scratch, my verdict might possibly be<br class="">different (but maybe we wouldn’t even allow types and values to share<br class="">names then…)<br class=""><br class=""><br class="">Please contradict me or indicate consensus by staying silent.<br class=""><br class=""><br class="">Greetings,<br class="">Joachim<br class=""><br class="">_______________________________________________<br class="">ghc-steering-committee mailing list<br class="">ghc-steering-committee@haskell.org<br class=""><br class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<br class=""></blockquote><br class="">--<br class="">Joachim Breitner<br class=""> <a href="mailto:mail@joachim-breitner.de" class="">mail@joachim-breitner.de</a><br class=""> <a href="http://www.joachim-breitner.de/" class="">http://www.joachim-breitner.de/</a><br class=""><br class="">_______________________________________________<br class="">ghc-steering-committee mailing list<br class=""><a href="mailto:ghc-steering-committee@haskell.org" class="">ghc-steering-committee@haskell.org</a><br class=""><br class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<br class=""></blockquote>--<br class="">Joachim Breitner<br class=""> <a href="mailto:mail@joachim-breitner.de" class="">mail@joachim-breitner.de</a><br class=""> <a href="http://www.joachim-breitner.de/" class="">http://www.joachim-breitner.de/</a><br class="">_______________________________________________<br class="">ghc-steering-committee mailing list<br class=""><a href="mailto:ghc-steering-committee@haskell.org" class="">ghc-steering-committee@haskell.org</a><br class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<br class=""></blockquote><br class=""><br class="">_______________________________________________<br class="">ghc-steering-committee mailing list<br class=""><a href="mailto:ghc-steering-committee@haskell.org" class="">ghc-steering-committee@haskell.org</a><br class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<br class=""><br class=""></blockquote><br class="">_______________________________________________<br class="">ghc-steering-committee mailing list<br class=""><a href="mailto:ghc-steering-committee@haskell.org" class="">ghc-steering-committee@haskell.org</a><br class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<br class=""><br class=""><br class=""><br class="">_______________________________________________<br class="">ghc-steering-committee mailing list<br class="">ghc-steering-committee@haskell.org<br class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<br class=""><br class=""></blockquote></div></div></blockquote></div><br class=""></body></html>