<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.Code, li.Code, div.Code
{mso-style-name:Code;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:9.0pt;
font-family:"Courier New";}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.hoenzb
{mso-style-name:hoenzb;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;
font-weight:normal;
font-style:normal;
text-decoration:none none;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
.MsoPapDefault
{mso-style-type:export-only;
margin-top:6.0pt;
margin-right:0cm;
margin-bottom:6.0pt;
margin-left:0cm;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-GB" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:12.0pt">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. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">So I think I’m in favour of (3), but with breaches of (1,2) handled with explicit judgement rather than cavalier disregard.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">Simon<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p></o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> ghc-steering-committee [mailto:ghc-steering-committee-bounces@haskell.org]
<b>On Behalf Of </b>Simon Marlow<br>
<b>Sent:</b> 17 October 2017 08:54<br>
<b>To:</b> Iavor Diatchki <iavor.diatchki@gmail.com><br>
<b>Cc:</b> ghc-steering-committee@haskell.org<br>
<b>Subject:</b> Re: [ghc-steering-committee] Proposal: Type Fixity (#65), Consensus: accept, own language extension?<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
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:<o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
1. LANGUAGE fully specifies the grammar of the source file<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
2. LANGUAGE fully specifies the grammar and semantics of the source file<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
Cheers<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
Simon<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<o:p> </o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<o:p> </o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
On 10 October 2017 at 03:54, Iavor Diatchki <<a href="mailto:iavor.diatchki@gmail.com" target="_blank">iavor.diatchki@gmail.com</a>> wrote:<o:p></o:p></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<o:p> </o:p></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:12.0pt;margin-left:0cm">
<o:p> </o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
Hello,<o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
my preference would be to add this to one of the existing extensions (either "explicit namespaces", or "type level operators"). <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<span style="color:#888888"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<span style="color:#888888">Iavor<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<span style="color:#888888"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<span style="color:#888888"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<span style="color:#888888"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<span style="color:#888888"><o:p> </o:p></span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
On Sat, Oct 7, 2017 at 11:26 AM Joachim Breitner <<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
Hi Committee,<br>
<br>
the discussion has ebbed down again. I observe that a clear majority is<br>
in favor. I don’t think there is a need for a formal vote, so I will<br>
proceed with this decision.<br>
<br>
Simon M brought up the next issue: Shall we require a separate language<br>
extension for this, or can it go under the hood of<br>
`ExplicitNamespaces`?<br>
<br>
So far Simon M expressed a strong preference for the former, while I am<br>
inclined to prefer the latter, and would like to hear a few more<br>
opinions on this detail (which certainly would set precedence for<br>
future decisions).<br>
<br>
Richard brought up the idea of versioned language extensions; that idea<br>
can certainly be investigated, but better independently. We have to<br>
deal with this proposal with the tools we have.<br>
<br>
Greetings,<br>
Joachim<br>
<br>
<br>
Am Mittwoch, den 20.09.2017, 12:23 -0400 schrieb Joachim Breitner:<br>
> Hi,<br>
><br>
> the type fixity proposal<br>
> (<a href="https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F65&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaac52c0ae0f4e79724608d515343160%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636438236268085142&sdata=d2EZ83iPvWUWKhtgqBEEXId4xg%2FAYHD2VFh6oM%2BwmQo%3D&reserved=0" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/65</a>)<br>
> was met with mixed reactions.<br>
><br>
> * I recommended rejection and Manuel strongly agrees with me.<br>
> * SPJ does not have strong opinions either way.<br>
> * Richard is in favor, and Iavor agrees.<br>
><br>
><br>
> Our process says “If consensus is elusive, then we vote, with the<br>
> Simons retaining veto power.” It looks like this might be such a case.<br>
> Should we go ahead and vote, or is more discussion likely to sway some<br>
> of us?<br>
><br>
> (I guess I can be swayed towards acceptance, especially if this<br>
> proposal re-uses existing syntactic idioms from export lists with<br>
> ExplicitNamespaces on.)<br>
><br>
> Greetings,<br>
> Joachim<br>
><br>
><br>
><br>
> Am Sonntag, den 27.08.2017, 20:16 +0200 schrieb Joachim Breitner:<br>
> > Dear Committee,<br>
> ><br>
> > Ryan Scott’s proposal to allow fixity declaration to explicitly target<br>
> > values or types has been brought before us:<br>
> > <a href="https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FRyanGlScott%2Fghc-proposals%2Fblob%2Ftype-infix%2F0000-type-infix.rst&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaac52c0ae0f4e79724608d515343160%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636438236268085142&sdata=9deOwM4rC4Ckum0lvNirj44NMIqXKzoiUPyMg4DgJQU%3D&reserved=0" target="_blank">
https://github.com/RyanGlScott/ghc-proposals/blob/type-infix/0000-type-infix.rst</a><br>
> > <a href="https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F65&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaac52c0ae0f4e79724608d515343160%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636438236268085142&sdata=d2EZ83iPvWUWKhtgqBEEXId4xg%2FAYHD2VFh6oM%2BwmQo%3D&reserved=0" target="_blank">
https://github.com/ghc-proposals/ghc-proposals/pull/65</a><br>
> ><br>
> > I (the secretary) nominates myself as the shepherd, so I can right away<br>
> > continue giving a recommendation.<br>
> ><br>
> > I propose to reject this proposal. The main reasons are:<br>
> > * it is not clear if there is a real use case for this. Has anyone<br>
> > ever complained about the status quo?<br>
> > The proposal does not motivate the need for a change well enough.<br>
> > (There is a related bug in TH, but that bug can probably simply be<br>
> > fixed.)<br>
> > * The status quo can be sold as a feature, rather than a short-coming.<br>
> > Namely that an operator has a fixed fixity, no matter what namespace<br>
> > it lives in.<br>
> > This matches morally what other languages do: In Gallina, fixity<br>
> > is assigned to names independent of their definition, AFAIK.<br>
> > * There is a non-trivial implementation and education overhead, a<br>
> > weight that is not pulled by the gains.<br>
> ><br>
> > If we’d design Haskell from scratch, my verdict might possibly be<br>
> > different (but maybe we wouldn’t even allow types and values to share<br>
> > names then…)<br>
> ><br>
> ><br>
> > Please contradict me or indicate consensus by staying silent.<br>
> ><br>
> ><br>
> > Greetings,<br>
> > Joachim<br>
> ><br>
> > _______________________________________________<br>
> > ghc-steering-committee mailing list<br>
> > <a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
> > <a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" target="_blank">
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
><br>
> --<br>
> Joachim Breitner<br>
> <a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a><br>
> <a href="https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaac52c0ae0f4e79724608d515343160%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636438236268085142&sdata=xvdf4zj1aKIfqxCMm%2B5DXZIrnha5Zu28YIngs3EFUE8%3D&reserved=0" target="_blank">http://www.joachim-breitner.de/</a><br>
><br>
> _______________________________________________<br>
> ghc-steering-committee mailing list<br>
> <a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
> <a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" target="_blank">
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
--<br>
Joachim Breitner<br>
<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a><br>
<a href="https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaac52c0ae0f4e79724608d515343160%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636438236268085142&sdata=xvdf4zj1aKIfqxCMm%2B5DXZIrnha5Zu28YIngs3EFUE8%3D&reserved=0" target="_blank">
http://www.joachim-breitner.de/</a><br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><o:p></o:p></p>
</blockquote>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:12.0pt;margin-left:0cm">
<br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><o:p></o:p></p>
</blockquote>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<o:p> </o:p></p>
</div>
</div>
</div>
</body>
</html>