[ghc-steering-committee] Proposal: Type Fixity (#65), Consensus: accept, own language extension?

[Iavor Diatchki]

Hello,

my preference would be to add this to one of the existing extensions
(either "explicit namespaces", or "type level operators").

Iavor





On Sat, Oct 7, 2017 at 11:26 AM Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi Committee,
>
> the discussion has ebbed down again. I observe that a clear majority is
> in favor. I don’t think there is a need for a formal vote, so I will
> proceed with this decision.
>
> Simon M brought up the next issue: Shall we require a separate language
> extension for this, or can it go under the hood of
> `ExplicitNamespaces`?
>
> So far Simon M expressed a strong preference for the former, while I am
>  inclined to prefer the latter, and would like to hear a few more
> opinions on this detail (which certainly would set precedence for
> future decisions).
>
> Richard brought up the idea of versioned language extensions; that idea
> can certainly be investigated, but better independently. We have to
> deal with this proposal with the tools we have.
>
> Greetings,
> Joachim
>
>
> Am Mittwoch, den 20.09.2017, 12:23 -0400 schrieb Joachim Breitner:
> > 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/
> >
> > _______________________________________________
> > 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/
> _______________________________________________
> 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/20171010/84134b97/attachment.html>