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

[Joachim Breitner]

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/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20171007/1ad97468/attachment.sig>