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

Tue Aug 29 08:42:44 UTC 2017

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 at justtesting.org]
Sent: 29 August 2017 01:30
To: Richard Eisenberg <rae at cs.brynmawr.edu>
Cc: Simon Peyton Jones <simonpj at microsoft.com>; ghc-steering-committee at haskell.org; Joachim Breitner <mail at joachim-breitner.de>
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 <rae at cs.brynmawr.edu<mailto:rae at 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 <simonpj at microsoft.com<mailto:simonpj at 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-319054892<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-325294776<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-325301080<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 at haskell.org<mailto:bounces at haskell.org>] On Behalf Of Joachim Breitner
|  Sent: 27 August 2017 19:16
|  To: ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at 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 at joachim-breitner.de<mailto:mail at 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 at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20170829/b89ffc20/attachment-0001.html>