<div dir="ltr">Could someone summarize the reason for the rejection? I do agree that this is a fairly corner case situation, but to me it clearly looks like a wart in the language---it is the only place in the language (I can think of) where we are conflating names from different namespaces.<div><br></div><div>It also seems quite surprising that this would have a significant implementation overhead, but I have not looked at what the issue might be.<div><br></div><div>-Iavor<br><div><br></div><div><br></div><div><br><div><div><br><div><br></div><div><br></div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Sep 20, 2017 at 9:32 AM Christopher Allen <<a href="mailto:cma@bitemyapp.com">cma@bitemyapp.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I concur with Manuel and Joachim's reasons for rejection, if we're<br>
headed to a vote.<br>
<br>
On Wed, Sep 20, 2017 at 11:23 AM, Joachim Breitner<br>
<<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a>> wrote:<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>
> 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>
> Joachim “nomeata” Breitner<br>
> <a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a><br>
> <a href="https://www.joachim-breitner.de/" rel="noreferrer" target="_blank">https://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>
<br>
<br>
<br>
--<br>
Chris Allen<br>
Currently working on <a href="http://haskellbook.com" rel="noreferrer" target="_blank">http://haskellbook.com</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>