Version 4 (modified by simonpj@…, 8 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").

## References

- Infix type constructors, classes, and type variables in the GHC User's Guide.

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

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

- Need to allow infix notation in contexts
f :: (a :>: b) => bla blah

- Watch out for code like this (http://hackage.haskell.org/trac/ghc/ticket/1727)
infixr 5 `Foo` infixr 6 `Bar` data a `Foo` b = a `FOO` a `Bar` b data a `Bar` b = a `BAR` b