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

[Iavor Diatchki]

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 <cma at bitemyapp.com> 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
> <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
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20170920/a944aebf/attachment-0001.html>