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

Wed Sep 20 20:11:23 UTC 2017

Hi,

the two reasons mentioned are:
 * Implementation and complexity overhead for a fringe wart.
 * It is an anti-feature if mentally parsing the structure of an
   expression "a + b * c" is not possible without knowing whether this
   is a term or a type. It is possible now, but only with serious
   effort (multiple modules).

Greetings,
Joachim

Am Mittwoch, den 20.09.2017, 17:42 +0000 schrieb 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/000
> > 0-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-c
> > ommittee
> > > --
> > > 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-co
> > mmittee
> > >
> > 
> > 
> > 
> > --
> > 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-comm
> > ittee
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-commit
> tee
-- 
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/20170920/c0431055/attachment.sig>