I don't have a strong opinion either way. The strongly reason in favour is encapsulated in Richard's comment
https://github.com/ghc-proposals/ghc-proposals/pull/65#issuecomment-319054892
which points out that the two T's are entirely unrelated.
I had not fully realised this, but in fact it is /already/ possible to have different fixities for a single lexeme T; a concrete example is here
https://github.com/ghc-proposals/ghc-proposals/pull/65#issuecomment-325294776
I added another comment
https://github.com/ghc-proposals/ghc-proposals/pull/65#issuecomment-325301080
that tries to separate the AST issue from the source-code issue. I do think we should make the internal change; but I’m unconvinced it’s worth the faff to solve the source-level issue.
Simon
| -----Original Message-----
| From: ghc-steering-committee [mailto:ghc-steering-committee-
| bounces@haskell.org] On Behalf Of Joachim Breitner
| Sent: 27 August 2017 19:16
| To: ghc-steering-committee@haskell.org
| Subject: [ghc-steering-committee] Proposal: Type Fixity (#65),
| Recommendation: Reject
|
| Dear Committee,
|
| Ryan Scott’s proposal to allow fixity declaration to explicitly target
| values or types has been brought before us:
| https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%
| 2FRyanGlScott%2Fghc-proposals%2Fblob%2Ftype-infix%2F0000-type-
| infix.rst&data=02%7C01%7Csimonpj%40microsoft.com%7Cf83d705bf55c4f02639b08d4e
| d77cb5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636394546146778107&sdat
| a=xa8HXiRK3uYOjGun7UUL3sKDVFvBVTFnXewe15pBGds%3D&reserved=0
| https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%
| proposals%2Fpull%2F65&data=02%7C01%7Csimonpj%40microsoft.com%7Cf83d705bf55c4
| f02639b08d4ed77cb5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63639454614
| 6778107&sdata=f5g17%2FpJdVe4vuwOAhrphyvXJakPFMS3yYZsi0sNG00%3D&reserved=0
|
| 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
|
| https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.joachim
| breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf83d705bf55c4f02639b
| 08d4ed77cb5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636394546146778107
| &sdata=PLDAZw6uCBkzRl7cjF00IomTmEAuqDKd7NNjbPWkpeE%3D&reserved=0