Opened 5 years ago

Closed 4 years ago

#6027 closed feature request (fixed)

Allow changing fixity of new type operators

Reported by: atnnn Owned by: pcapriotti
Priority: normal Milestone: 7.6.1
Component: Compiler Version: 7.5
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


Here is the problem:

{-# LANGUAGE TypeOperators #-}
type (&) = ()
data (?)
class (#)
infixr 2 &
infixr 2 ?
infixr 2 #
    The fixity signature for `&' lacks an accompanying binding

    The fixity signature for `?' lacks an accompanying binding

    The fixity signature for `#' lacks an accompanying binding

My solution is inspired by the 'type' keyword in the export list.

infixr 2 type &
infixr 2 type ?, type #

Attachments (3)

type-op-fixity.patch (489 bytes) - added by atnnn 5 years ago.
this patch has arguments in the correct order
6027.patch (4.7 KB) - added by pcapriotti 4 years ago.
6027-tests.patch (2.2 KB) - added by pcapriotti 4 years ago.

Download all attachments as: .zip

Change History (10)

Changed 5 years ago by atnnn

this patch has arguments in the correct order

comment:1 Changed 5 years ago by simonpj

  • difficulty set to Unknown
  • Milestone set to 7.6.1
  • Owner set to pcapriotti

Currently in GHC changing the fixity of a term-level operator, such as (+) also changes the fixity of the corresponding type-level operator. We could have different fixities for the term-level (+) than the type level (+), but it would be confusing!

So rather than les tyou specify different fixities for each, as your patch implies, I think it'd be better simply to make infixr 2 ? work even when there is only a type-level (?) in scope.

Paolo might you look at this? (It in the renamer, not a big deal I think.)


comment:2 Changed 5 years ago by pcapriotti

  • Status changed from new to patch

I believe the current behavior is just an unintended consequence of the new type operator syntax.

Fixity declarations are already resolved in the TcClsName namespace, but only if the reader name is in DataName.

The attached patch relaxes this constraints, and always looks up fixity declaration names in TcClsName, as well as the original namespace.

comment:3 Changed 5 years ago by simonpj

Yes that looks right. But it took me a little while to figure out how your change worked. In effect lookupFixSigNames and lookupLocalDataTcNames are identical except that

  • The latter has a special case for Exact names; it would do no harm for this to be used in both
  • lookupFixSigNames, used ony in fixity signatures, always adds a TcClsName
  • lookupLocalDataTcNames, used only in warnings (rnSrcWarnDecls), adds a TcClsName to a DataName.

The difference is troubling, and I bet it should not exist. Can we just combine the two? And then you won't need to separate out lookupMultipleNames.

And add a Note that gives an example, both of giving fixity for a type constructor, and for a type constructor operator.


Changed 4 years ago by pcapriotti

Changed 4 years ago by pcapriotti

comment:4 Changed 4 years ago by pcapriotti

Simon, you're right. The other places using lookupLocalDataTcNames also need the extended lookup now that type operators are not necessarily parsed as DataName.

I updated the patch, and added two test cases: one for the original issue, and one that shows the correct lookup behavior of :info in GHCi.

comment:5 Changed 4 years ago by simonpj

OK good. go ahead and push, thanks

comment:6 Changed 4 years ago by p.capriotti@…

commit 5bfd8933024cb2120c38e01346b1b47d6dde10cb

Author: Paolo Capriotti <>
Date:   Wed Apr 25 14:10:40 2012 +0100

    Fix lookup of fixity signatures for type operators (#6027)
    Extend name lookup for fixity declaration to the TcClsName namespace for
    all reader names, instead of only those in DataName.

 compiler/rename/RnEnv.lhs    |   58 +++++++++++++++++++++++++++++-------------
 compiler/rename/RnSource.lhs |    4 +-
 2 files changed, 42 insertions(+), 20 deletions(-)

comment:7 Changed 4 years ago by pcapriotti

  • Resolution set to fixed
  • Status changed from patch to closed

The implementation of dataTcOccs in the above commit is slightly different from that of the patch, since we have to avoid generating two results when looking up something which is already in the TcClsName namespace, as can happen using :info in GHCi (testcase ghci020 would break).

Note: See TracTickets for help on using tickets.