[ghc-steering-committee] Proposal: Type Fixity (#65), Recommendation: Reject

[Christopher Allen]

I concur with Manuel and Joachim's reasons for rejection, if we're
headed to a vote.

On Wed, Sep 20, 2017 at 11:23 AM, Joachim Breitner
<mail at joachim-breitner.de> wrote:
> 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/
>
> --
> Joachim “nomeata” Breitner
>   mail at joachim-breitner.de
>   https://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