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

Wed Sep 20 22:43:19 UTC 2017

I remain in favor of this proposal and currently feel unlikely to be swayed. (But I will continue to read and seriously consider dissenting viewpoints, of course.)

In an attempt to convince others of my stance, let me address directly the reasons against that have been brought forth here:

Joachim writes:
> * it is not clear if there is a real use case for this. Has anyone
>   ever complained about the status quo?

I have found this jarring for years. But I'm not sure I'm enough of a Real User to count. (where "this" = one Haskell construct which, in opposition to all others, considers the similar spelling of a type-level name and a term-level name to have an effect on the meaning of a program)

>   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.)

Agreed that the TH bug could be fixed without this proposal.

> * 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.

I'm not sure exactly what this means. The type-level (*) and the term-level (*) are different operators. Perhaps you mean "Namely that all operators that have the same spelling have a fixed fixity, ...", but then we're back to the construct giving a semantics to the similar spelling of two definitions.

>   This matches morally what other languages do: In Gallina, fixity
>   is assigned to names independent of their definition, AFAIK.

I don't think this issue has a counterpart in, e.g., Gallina. This is because Gallina just has one namespace, so the set of all operators that have the same spelling has at most one element.

> * There is a non-trivial implementation and education overhead, a
>   weight that is not pulled by the gains.

I argue that the education overhead is in explaining the status quo, and the proposal reduces the education overhead. Anecdote: a student in my Haskell class last semester asked, unbidden, how it was that one fixity declaration affects two separate definitions, and I had to explain this very conundrum.

Manuel writes:
> 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).

I agree here -- fixities are possible to abuse horribly and are difficult to work with.

> Using different fixity declarations for the same operator name on the value and type level seems a sure way to increase confusion.

Yet here I disagree: I reject the notion of the "same operator". A definition (data a :*: b = a :*: b) defines two operators that have the same spelling, just like (data T a b = T a b) defines two identifiers spelled "T". Note that the two (:*:)s have different types, just like the two `T`s. I don't sit comfortably calling two things with different types the "same". :)

Could this new feature proposed be abused? Absolutely. But I don't think the potential for abuse should stop us, given that library-writers already have abused everything in sight -- and sometimes to good effect! (For example, the original HList is an abuse of functional dependencies but has spawned an entire cottage industry of type-level shenanigans.)

I should also address why I care about this: Since its inception, Haskell has had the ability to use the same name in types as in terms. I think for much of this time, the type/term boundary wasn't seen so much as a pair of namespaces as essentially two different languages. Some set of constructs was available in terms, and a different set was available in types. Because they were separate languages, it was natural for them to have separate namespaces. And it might even be reasonable to talk about the "same" construct existing in both. After all, of course the constructs aren't *really* the same, as they exist in different languages. (Much like when we say that () is the same as C's void... but of course they're not *really* the same.)

Now, however, with the advent of DataKinds and TypeInType, we are actively blurring the separation between the languages. Yet we still allow constructs like "data T = T". So we need a new way of thinking about such declarations to stop us from getting confused -- and my approach is to consider that Haskell simply has two namespaces. (Actually, it has more than that, given that lower-case names live apart from upper-case ones. But I digress.) Namespaces are a relatively ubiquitous concept in programming, and so the situation can be easily explained and learned. I have been pushing my model of namespaces in talking about the ' used to write data constructors in types as a namespace selection operator, not a "promotion" operator.

The current status quo of fixity declarations pierces a hole in this model of Haskell's namespaces. And so I find it quite distasteful and wish to patch the hole.

(I hope I don't need to say that, of course, I'll go along with a majority vote on the matter and move on to those other raw fish, should my little manifesto here not win the day.)

Thanks for reading,
Richard

> 
> 
> On Sep 20, 2017, at 12:31 PM, 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/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
>> 
> 
> 
> 
> -- 
> 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-committee