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

[Manuel M T Chakravarty]

I am strongly against this proposal. User-defined fixities are already a feature that needs to be used with care, carrying the danger that the user of an API with ample operators with custom fixities needs to memorise many, often somewhat arbitrary numbers (i.e., precedence levels). Using different fixity declarations for the same operator name on the value and type level seems a sure way to increase confusion. I am very much against it.

Manuel

> Joachim Breitner <mail at joachim-breitner.de>:
> 
> 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
> 
> -- 
> 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