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

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. It also seems quite surprising that this would have a significant implementation overhead, but I have not looked at what the issue might be. -Iavor On Wed, Sep 20, 2017 at 9:32 AM Christopher Allen wrote:

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 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...

...

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@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

-- Joachim “nomeata” Breitner mail@joachim-breitner.de https://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-- Chris Allen Currently working on http://haskellbook.com _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee