IMHO, it is a bug that you can provide different fixities in different modules and we should fix that bug. Manuel

Richard Eisenberg :

Unsurprisingly, I'm in favor of this proposal and do not wish to reject.

To me, the wart on the language is that we can use the same string for a term-level name and a potentially unrelated type-level name. Of course, this has served many people well, but it does create a certain awkwardness in places (and confusion for beginners!). As long as we have the possibility of one string representing two potentially unrelated names, it seems to be a weakness in expressiveness not to be able to assign different fixities to the names. (And indeed we *can* assign different fixities, as long as we do so in different modules.)

On the other hand, I am sensitive about all those other raw fish that need frying...

Richard

...

On Aug 28, 2017, at 5:05 AM, Simon Peyton Jones mailto:simonpj@microsoft.com> wrote:

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-31905489... https://github.com/ghc-proposals/ghc-proposals/pull/65#issuecomment-31905489... 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-32529477... https://github.com/ghc-proposals/ghc-proposals/pull/65#issuecomment-32529477...

I added another comment https://github.com/ghc-proposals/ghc-proposals/pull/65#issuecomment-32530108... https://github.com/ghc-proposals/ghc-proposals/pull/65#issuecomment-32530108... 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 mailto:bounces@haskell.org] On Behalf Of Joachim Breitner | Sent: 27 August 2017 19:16 | To: ghc-steering-committee@haskell.org mailto: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% 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%7Cf83d705bf55c4f02639b08d4ed77cb5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636394546146778107&sdata=xa8HXiRK3uYOjGun7UUL3sKDVFvBVTFnXewe15pBGds%3D&reserved=0 |  2FRyanGlScott%2Fghc-proposals%2Fblob%2Ftype-infix%2F0000-type- 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%7Cf83d705bf55c4f02639b08d4ed77cb5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636394546146778107&sdata=xa8HXiRK3uYOjGun7UUL3sKDVFvBVTFnXewe15pBGds%3D&reserved=0 |  infix.rst&data=02%7C01%7Csimonpj%40microsoft.com%7Cf83d705bf55c4f02639b08d4e 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%7Cf83d705bf55c4f02639b08d4ed77cb5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636394546146778107&sdata=xa8HXiRK3uYOjGun7UUL3sKDVFvBVTFnXewe15pBGds%3D&reserved=0 |  d77cb5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636394546146778107&sdat 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%7Cf83d705bf55c4f02639b08d4ed77cb5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636394546146778107&sdata=xa8HXiRK3uYOjGun7UUL3sKDVFvBVTFnXewe15pBGds%3D&reserved=0 |  a=xa8HXiRK3uYOjGun7UUL3sKDVFvBVTFnXewe15pBGds%3D&reserved=0 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%7Cf83d705bf55c4f02639b08d4ed77cb5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636394546146778107&sdata=xa8HXiRK3uYOjGun7UUL3sKDVFvBVTFnXewe15pBGds%3D&reserved=0 | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com% https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F65&data=02%7C01%7Csimonpj%40microsoft.com%7Cf83d705bf55c4f02639b08d4ed77cb5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636394546146778107&sdata=f5g17%2FpJdVe4vuwOAhrphyvXJakPFMS3yYZsi0sNG00%3D&reserved=0 |  2Fghc-proposals%2Fghc- https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F65&data=02%7C01%7Csimonpj%40microsoft.com%7Cf83d705bf55c4f02639b08d4ed77cb5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636394546146778107&sdata=f5g17%2FpJdVe4vuwOAhrphyvXJakPFMS3yYZsi0sNG00%3D&reserved=0 |  proposals%2Fpull%2F65&data=02%7C01%7Csimonpj%40microsoft.com%7Cf83d705bf55c4 https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F65&data=02%7C01%7Csimonpj%40microsoft.com%7Cf83d705bf55c4f02639b08d4ed77cb5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636394546146778107&sdata=f5g17%2FpJdVe4vuwOAhrphyvXJakPFMS3yYZsi0sNG00%3D&reserved=0 |  f02639b08d4ed77cb5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63639454614 https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F65&data=02%7C01%7Csimonpj%40microsoft.com%7Cf83d705bf55c4f02639b08d4ed77cb5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636394546146778107&sdata=f5g17%2FpJdVe4vuwOAhrphyvXJakPFMS3yYZsi0sNG00%3D&reserved=0 |  6778107&sdata=f5g17%2FpJdVe4vuwOAhrphyvXJakPFMS3yYZsi0sNG00%3D&reserved=0 https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F65&data=02%7C01%7Csimonpj%40microsoft.com%7Cf83d705bf55c4f02639b08d4ed77cb5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636394546146778107&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 | mail@joachim-breitner.de mailto:mail@joachim-breitner.de | | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.joachim https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf83d705bf55c4f02639b08d4ed77cb5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636394546146778107&sdata=PLDAZw6uCBkzRl7cjF00IomTmEAuqDKd7NNjbPWkpeE%3D&reserved=0 |  - https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf83d705bf55c4f02639b08d4ed77cb5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636394546146778107&sdata=PLDAZw6uCBkzRl7cjF00IomTmEAuqDKd7NNjbPWkpeE%3D&reserved=0 |  breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf83d705bf55c4f02639b https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf83d705bf55c4f02639b08d4ed77cb5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636394546146778107&sdata=PLDAZw6uCBkzRl7cjF00IomTmEAuqDKd7NNjbPWkpeE%3D&reserved=0 |  08d4ed77cb5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636394546146778107 https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf83d705bf55c4f02639b08d4ed77cb5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636394546146778107&sdata=PLDAZw6uCBkzRl7cjF00IomTmEAuqDKd7NNjbPWkpeE%3D&reserved=0 |  &sdata=PLDAZw6uCBkzRl7cjF00IomTmEAuqDKd7NNjbPWkpeE%3D&reserved=0 https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf83d705bf55c4f02639b08d4ed77cb5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636394546146778107&sdata=PLDAZw6uCBkzRl7cjF00IomTmEAuqDKd7NNjbPWkpeE%3D&reserved=0_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

---

ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

IMHO, it is a bug that you can provide different fixities in different modules and we should fix that bug. Doing so would require a design in its own right – a new GHC proposal in fact. The Haskell 2010 report specifically specifies that fixity is a property of an entity, not a lexeme. Remember those two modules might come from utterly different libraries A and B, written by different authors at different times. We can hardly say that it’s an error to use them together! S From: Manuel M T Chakravarty [mailto:chak@justtesting.org] Sent: 29 August 2017 01:30 To: Richard Eisenberg Cc: Simon Peyton Jones ; ghc-steering-committee@haskell.org; Joachim Breitner Subject: Re: [ghc-steering-committee] Proposal: Type Fixity (#65), Recommendation: Reject IMHO, it is a bug that you can provide different fixities in different modules and we should fix that bug. Manuel Richard Eisenberg mailto:rae@cs.brynmawr.edu>: Unsurprisingly, I'm in favor of this proposal and do not wish to reject. To me, the wart on the language is that we can use the same string for a term-level name and a potentially unrelated type-level name. Of course, this has served many people well, but it does create a certain awkwardness in places (and confusion for beginners!). As long as we have the possibility of one string representing two potentially unrelated names, it seems to be a weakness in expressiveness not to be able to assign different fixities to the names. (And indeed we *can* assign different fixities, as long as we do so in different modules.) On the other hand, I am sensitive about all those other raw fish that need frying... Richard On Aug 28, 2017, at 5:05 AM, Simon Peyton Jones mailto:simonpj@microsoft.com> wrote: 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-31905489...https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F65%23issuecomment-319054892&data=02%7C01%7Csimonpj%40microsoft.com%7C59e710e85d2747a969ea08d4ee752a6d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636395634384317201&sdata=tJqG%2F7szZUU%2Fpl4GL53x5nBvU%2F9O4iD5Xfb79WnKiYM%3D&reserved=0 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-32529477...https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F65%23issuecomment-325294776&data=02%7C01%7Csimonpj%40microsoft.com%7C59e710e85d2747a969ea08d4ee752a6d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636395634384317201&sdata=UDVwzfeeS3SbIRq9BBjgVn%2B22BFGw17hwqLXITUSxu8%3D&reserved=0 I added another comment https://github.com/ghc-proposals/ghc-proposals/pull/65#issuecomment-32530108...https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F65%23issuecomment-325301080&data=02%7C01%7Csimonpj%40microsoft.com%7C59e710e85d2747a969ea08d4ee752a6d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636395634384317201&sdata=imesKT5ZJvCgyU5m%2FA5%2BDChTnPF2lR1VtIkVpOFBpbU%3D&reserved=0 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.orgmailto:bounces@haskell.org] On Behalf Of Joachim Breitner | Sent: 27 August 2017 19:16 | To: ghc-steering-committee@haskell.orgmailto: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%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%7Cf83d705bf55c4f02639b08d4ed77cb5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636394546146778107&sdata=xa8HXiRK3uYOjGun7UUL3sKDVFvBVTFnXewe15pBGds%3D&reserved=0 | 2FRyanGlScott%2Fghc-proposals%2Fblob%2Ftype-infix%2F0000-type-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%7Cf83d705bf55c4f02639b08d4ed77cb5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636394546146778107&sdata=xa8HXiRK3uYOjGun7UUL3sKDVFvBVTFnXewe15pBGds%3D&reserved=0 | infix.rst&data=02%7C01%7Csimonpj%40microsoft.com%7Cf83d705bf55c4f02639b08d4ehttps://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%7Cf83d705bf55c4f02639b08d4ed77cb5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636394546146778107&sdata=xa8HXiRK3uYOjGun7UUL3sKDVFvBVTFnXewe15pBGds%3D&reserved=0 | d77cb5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636394546146778107&sdathttps://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%7Cf83d705bf55c4f02639b08d4ed77cb5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636394546146778107&sdata=xa8HXiRK3uYOjGun7UUL3sKDVFvBVTFnXewe15pBGds%3D&reserved=0 | a=xa8HXiRK3uYOjGun7UUL3sKDVFvBVTFnXewe15pBGds%3D&reserved=0https://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%7Cf83d705bf55c4f02639b08d4ed77cb5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636394546146778107&sdata=xa8HXiRK3uYOjGun7UUL3sKDVFvBVTFnXewe15pBGds%3D&reserved=0 | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F65&data=02%7C01%7Csimonpj%40microsoft.com%7Cf83d705bf55c4f02639b08d4ed77cb5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636394546146778107&sdata=f5g17%2FpJdVe4vuwOAhrphyvXJakPFMS3yYZsi0sNG00%3D&reserved=0 | 2Fghc-proposals%2Fghc-https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F65&data=02%7C01%7Csimonpj%40microsoft.com%7Cf83d705bf55c4f02639b08d4ed77cb5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636394546146778107&sdata=f5g17%2FpJdVe4vuwOAhrphyvXJakPFMS3yYZsi0sNG00%3D&reserved=0 | proposals%2Fpull%2F65&data=02%7C01%7Csimonpj%40microsoft.com%7Cf83d705bf55c4https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F65&data=02%7C01%7Csimonpj%40microsoft.com%7Cf83d705bf55c4f02639b08d4ed77cb5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636394546146778107&sdata=f5g17%2FpJdVe4vuwOAhrphyvXJakPFMS3yYZsi0sNG00%3D&reserved=0 | f02639b08d4ed77cb5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63639454614https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F65&data=02%7C01%7Csimonpj%40microsoft.com%7Cf83d705bf55c4f02639b08d4ed77cb5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636394546146778107&sdata=f5g17%2FpJdVe4vuwOAhrphyvXJakPFMS3yYZsi0sNG00%3D&reserved=0 | 6778107&sdata=f5g17%2FpJdVe4vuwOAhrphyvXJakPFMS3yYZsi0sNG00%3D&reserved=0https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F65&data=02%7C01%7Csimonpj%40microsoft.com%7Cf83d705bf55c4f02639b08d4ed77cb5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636394546146778107&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 | mail@joachim-breitner.demailto:mail@joachim-breitner.de | | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.joachimhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf83d705bf55c4f02639b08d4ed77cb5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636394546146778107&sdata=PLDAZw6uCBkzRl7cjF00IomTmEAuqDKd7NNjbPWkpeE%3D&reserved=0 | -https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf83d705bf55c4f02639b08d4ed77cb5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636394546146778107&sdata=PLDAZw6uCBkzRl7cjF00IomTmEAuqDKd7NNjbPWkpeE%3D&reserved=0 | breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf83d705bf55c4f02639bhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf83d705bf55c4f02639b08d4ed77cb5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636394546146778107&sdata=PLDAZw6uCBkzRl7cjF00IomTmEAuqDKd7NNjbPWkpeE%3D&reserved=0 | 08d4ed77cb5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636394546146778107https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf83d705bf55c4f02639b08d4ed77cb5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636394546146778107&sdata=PLDAZw6uCBkzRl7cjF00IomTmEAuqDKd7NNjbPWkpeE%3D&reserved=0 | &sdata=PLDAZw6uCBkzRl7cjF00IomTmEAuqDKd7NNjbPWkpeE%3D&reserved=0https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf83d705bf55c4f02639b08d4ed77cb5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636394546146778107&sdata=PLDAZw6uCBkzRl7cjF00IomTmEAuqDKd7NNjbPWkpeE%3D&reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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 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... 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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

-- Joachim “nomeata” Breitner mail@joachim-breitner.de https://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-- Chris Allen Currently working on http://haskellbook.com

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 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 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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c ommittee -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

-- Joachim “nomeata” Breitner mail@joachim-breitner.de https://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-comm ittee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-commit tee -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

I'm quite ambivalent about this but would vote yes if it came to that. It does fix a little wart, people seem to want it strongly and I wouldn't ban it from our code base. Thanks, Roman

On 20 Sep 2017, at 23:43, Richard Eisenberg wrote:

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 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 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... 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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

-- Joachim “nomeata” Breitner mail@joachim-breitner.de https://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Hi, the vote seems to indicate acceptance so far; fine with me. Am Donnerstag, den 21.09.2017, 08:46 +0100 schrieb Simon Marlow:

However, if we do accept the proposal, it should have its own extension rather than being part of ExplicitNamespaces, for the reasons discussed earlier: code needs a way to declare that it is using a new extension, so that it can properly be rejected by older versions of the compiler that don't support the extension.

Earlier we discussed the question of whether we want to allow minor changes to unextendd Haskell without extensions (and the consensus was no). This does not imply that we forbid ourselves from extending the range of existing GHC language pragmas. From a user point of view, having “ExplicitNamespaces” allow me to explicitly name the namespaces of an identifier in identifier lists such as export, import and fixity lists is very natural. It would be strange if I need “ExplicitNamespaces” for export and import lists, but “ExplicitNamespacesFixities” in fixitiy lists. I am sure others can give concrete examples where the syntax of language extensions has evolved without introducing a wealth of new extensions (and having to support all combinations). TemplateHaskell splices maybe? RebindableSyntax maybe? So is there a sensible way we can avoid fringe language extension pragma proliferation? Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Hi, Am Dienstag, den 26.09.2017, 20:10 +0100 schrieb Simon Marlow:

It's a tradeoff and we could go either way, but I'll argue for being strict here. Suppose we have some code that uses the new extension and I compile it with GHC 8.2. The choice is between:

* without a new extension flag, GHC says "Parse error" * with a new extension flag, GHC says "Extension not supported", and in fact we might not even get that far because our tooling might tell us that we can't compile this code before we even try. Or Cabal could choose a different (and supported) version of the package instead.

It's a choice between having metadata and a bit of extra work, vs. having no metadata and things sometimes failing.

it is also a choice between * extensions are testbeds and playgrounds for language extensions * extensions are what people build their products with I guess at some point, the former was true, and it was so successful that the second became true. I’d be sad if this leads to language extensions having to live up to the expectations to be perfect right from the start, and not be allowed to improve over a few releases. But I see the benefit of stability. Is it feasible to communicate their stability somehow? Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

If you see my comment https://github.com/ghc-proposals/ghc-proposals/pull/65#issuecomment-32530108... you'll see that I finally realised that GHC (and indeed H98) /already/ allows different fixities for term and type level. So now I'm more supportive: it's become /solely/ a question of whether we supply concrete syntax to allow us to do something on one module that we can /already/ do (perhaps inconveniently) with two. So I'm now mildly in favour. Simon | -----Original Message----- | From: ghc-steering-committee [mailto:ghc-steering-committee- | bounces@haskell.org] On Behalf Of Joachim Breitner | Sent: 20 September 2017 17:24 | To: ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] Proposal: Type Fixity (#65), | Recommendation: Reject | | Hi, | | the type fixity proposal | (https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com | %2Fghc-proposals%2Fghc- | proposals%2Fpull%2F65&data=02%7C01%7Csimonpj%40microsoft.com%7Cc0583aed4fbd4 | f37a40a08d500441d81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63641521490 | 8671210&sdata=%2F9oJkejSngjz%2FGy12Q%2FJlPOzzFdT%2FHD9SslPffMcA60%3D&reserve | d=0) | 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu | > b.com%2FRyanGlScott%2Fghc-proposals%2Fblob%2Ftype-infix%2F0000-type-in | > fix.rst&data=02%7C01%7Csimonpj%40microsoft.com%7Cc0583aed4fbd4f37a40a0 | > 8d500441d81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6364152149086 | > 71210&sdata=1qRrPKmHWYpB9XRFOHwiJT2Kwc%2B%2BOtf0vm0ibOWuTQI%3D&reserve | > d=0 | > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu | > b.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F65&data=02%7C01%7Csimon | > pj%40microsoft.com%7Cc0583aed4fbd4f37a40a08d500441d81%7C72f988bf86f141 | > af91ab2d7cd011db47%7C1%7C0%7C636415214908671210&sdata=%2F9oJkejSngjz%2 | > FGy12Q%2FJlPOzzFdT%2FHD9SslPffMcA60%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 | > | > _______________________________________________ | > ghc-steering-committee mailing list | > ghc-steering-committee@haskell.org | > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committ | > ee | -- | Joachim Breitner | mail@joachim-breitner.de | | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim- | breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cc0583aed4fbd4f37a40a | 08d500441d81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636415214908671210 | &sdata=73MgFmM8BOaWVRs4%2BMi3iLBpNcDip7g2DLVsEesYbuw%3D&reserved=0 | | -- | Joachim “nomeata” Breitner | mail@joachim-breitner.de | | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.joachim | - | breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cc0583aed4fbd4f37a40a | 08d500441d81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636415214908671210 | &sdata=5nSTzp%2FXxt7bGfgRTY0r4qlMn83jTfv1hkTetc34ihg%3D&reserved=0