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

Tue Aug 29 06:18:15 UTC 2017

Hello,

I think that we should accept this proposal.

My reasoning is as follows:
   * in traditional Haskell (e.g., 98, 2010) fixities are associated with
specific declarations, thus the same name always has the same fixity, no
matter in which module it is used.
   * I think that this is not a bug, but a feature:  fixities would be
basically unusable if they kept changiing, or somehow all libraries had to
agree on using a specific fixity ahead of time---even when they use the
same name for completely different purposes (let alone type vs. value).
   * I find the current design for `TypeOprators` to be confusing, as a
single fixity declaration, sets the fixties of two completely unrelated
names---one in the value namespace and one in the type namespace: assuming
that these two have anything to with each other seems to be a mistake.
   * the propsal suggests a rather natural way to resolve this.

-Iavor

On Tue, Aug 29, 2017 at 3:30 AM Manuel M T Chakravarty <chak at justtesting.org>
wrote:

> 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>:
>
>
> 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>
> 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
> 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 at haskell.org] On Behalf Of Joachim Breitner
> |  Sent: 27 August 2017 19:16
> |  To: 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
> |
> |
> 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
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> 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
> 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/10e0edc0/attachment-0001.html>