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

[Simon Marlow]

I don't have strong opinions on this proposal, but I suppose I'm weakly in
favour because there's no reason to expect that the natural fixity for an
operator used at the type level should be the same as the operator used at
the value level.  On the other hand, it seems like a fix for a very narrow
problem, so I agree with Joachim's point that the motivation to make a
change here seems weak.

However, if we do accept the proposal, it should have its own extension
rather than being part of ExplicitNamespaces, for the reasons discussed
earlier: code needs a way to declare that it is using a new extension, so
that it can properly be rejected by older versions of the compiler that
don't support the extension.

Cheers
Simon

On 20 September 2017 at 17:23, 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20170921/1a66d980/attachment.html>