<div dir="ltr"><div class="gmail_quote"><div dir="ltr"><br></div><br><br><div dir="ltr">Hello,<div><br></div><div>my preference would be to add this to one of the existing extensions (either "explicit namespaces", or "type level operators").     </div></div><div dir="ltr"><div><br></div><div>Iavor</div><div><br></div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">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:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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://github.com/ghc-proposals/ghc-proposals/pull/65" rel="noreferrer" 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://github.com/RyanGlScott/ghc-proposals/blob/type-infix/0000-type-infix.rst" rel="noreferrer" target="_blank">https://github.com/RyanGlScott/ghc-proposals/blob/type-infix/0000-type-infix.rst</a><br>
> > <a href="https://github.com/ghc-proposals/ghc-proposals/pull/65" rel="noreferrer" 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" rel="noreferrer" 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="http://www.joachim-breitner.de/" rel="noreferrer" 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" rel="noreferrer" 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="http://www.joachim-breitner.de/" rel="noreferrer" 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" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div></div></div>