wiki:InfixTypeConstructors

Version 5 (modified by simonpj@…, 6 years ago) (diff)

--

Infix Type Constructors

Brief Explanation

First proposal: allow infix notation in types, in two forms:

  • Regular names in back quotes. This works for type constructors (eg a `TyCon` b) and type variables (eg Int `a` Bool)
  • Operator symbols (e.g. (a + b), or (a :+: b).

Second proposal, make both varsyms and consyms be type constructors. That would allow us to say this:

        data a + b = Left a | Right b

That is, we want to define the type constructor (+). GHC's current choice (done for a pseudo-consistency with the value level) is to allow only consyms as type constructors. So we cannot give the declaration above (because (+) is a type variable. Instead we can say only this:

        data a :+ b = Left a | Right b

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

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.

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 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").

References

Tickets

#78
Add infix type constructors

Pros

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

Cons

  • If operators are type constructors, they can't also be type variables. I know one place where people use a type variable that is an operator. Something like this.
            data T (~>) = MkT (Int ~> Int)
    

We'd have to use a type variable in back-quotes instead.

Observations

  • 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.