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 <rae@cs.brynmawr.edu>
Cc: Simon Peyton Jones <simonpj@microsoft.com>; ghc-steering-committee@haskell.org; Joachim Breitner <mail@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@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@microsoft.com> wrote:

 

I don't have a strong opinion either way. The strongly reason in favour is encapsulated in Richard's comment

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

 

I added another comment

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

|  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:

|  

|  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

|  

_______________________________________________
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