Version 4 (modified by simonpj@…, 7 years ago) (diff)

Infix Type Constructors

Brief Explanation

GHC allows type constructors to be infix operators (conops, beginning with :, but not including : itself).

Changes to the syntax may depend on whether CompositionAsDot is adopted, but roughly speaking we add

 qtycon   -> qconid  | ( qconsym )
 qtyconop -> qconsym | ` qconid `

And type gets an extra production:

 type    -> btype qtyconop type

(modulo FixityResolution). Also, there are obvious changes to the grammar for type, data, and newtype declarations.

Secondly, I propose to allow varsyms to be used as type constructors. For example, currently "+" is a varsym, so at the type level it'd behave like a type variable

        data T (+) = MkT (Int + Int)

It's not impossible that this might be useful, although the binding site looks clumsy. But it misses a much more useful opportunity. What we want is to say

        data a + b = Left a | Right b

That is, we want to define the type constructor (+). Currently we have to use the clumsy :+ notation:

        data a :+ b = Left a | Right b

Yuk. So I propose that varsyms can be used as type constructors, and not as type variables.

You may say that is inconsistent, because at the value level you have to start data constructors with a ":". But the type level is already funny. The whole type-family idea (beginning with type synonyms) defines things that begin with a capital letter, but which (unlike data constructors) are not head normal forms. By the time we have full type-synonym families, they really are *functions* as much as any value-level function is.

Some people use Haskell as a laboratory in which to write their cunning type ideas. In mathematics, operators are invariably top-level type constructors (think of the type a+b). Mirroring this in Haskell would make the transcription more elegantly direct.

I can't think of any down-sides, except the slight loss of consistency ("the hobgoblin of tiny minds").



Add infix type constructors


  • This is a straightforward generalisation, doesn't break any existing code, and improves the consistency of the syntax.



  • Note that classes can be infix too; this is useful.
  • If you say module M( (+) ) where ... are you exporting the type constructor (+) or the value (+)? Ditto import lists. Possibilities:
    • An ambiguous reference defaults to the locally-defined one. (If we did this we should do so consistently, including for unqualified names in the text of a module. I think this'd be a Good Thing. A warning flag could warn if you used it. It's just like shadowing.)
    • If the two (+) things are not both locally defined, you can disambiguate with a qualified name Prelude.(+) or M.(+). That does not help if you define both in M.
    • Use a keyword to distinguish; eg module M( data (+) ) where. There are design issues here (e.g. distinguish data and newtype?).
  • Can you set the fixity of a type constructor T differently than the data constructor T? This is a similar ambiguity to the one in export lists. Except that in this case it is very common to have a type constructor and data constructor with the same name.