Changes between Version 5 and Version 6 of InfixTypeConstructors


Ignore:
Timestamp:
Oct 9, 2008 7:55:53 AM (7 years ago)
Author:
simonpj@…
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • InfixTypeConstructors

    v5 v6  
    3434(modulo FixityResolution).  Also, there are obvious changes to the grammar for {{{type}}}, {{{data}}}, and {{{newtype}}} declarations.
    3535
    36 
    37 
    38 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.
    39 
    4036Some people use  constructors (think of the type a+b).  Mirroring this in Haskell would make the transcription more elegantly direct.
    4137
    4238I can't think of any down-sides, except the slight loss of consistency ("the hobgoblin of tiny minds").
    4339
     40== Observations ==
    4441
    45 == References ==
    46 
    47  * [http://www.haskell.org/ghc/docs/latest/html/users_guide/type-extensions.html#infix-tycons  Infix type constructors, classes, and type variables] in the GHC User's Guide.
    48 
    49 == Tickets ==
    50 [[TicketQuery(description~=InfixTypeConstructors)]]
    51 
    52 == Pros ==
    53  * This is a straightforward generalisation, doesn't break any existing code, and improves the consistency of the syntax.
    54 
    55 == Cons ==
    56 
    57 * 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.
     42 * You may say that it's inconsistent for `(+)` to range over type constructors, 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 (including H98  type synonyms) defines things that begin with a capital letter, but which (unlike data constructors) are not head normal forms.  Looking further ahead, by the time we have full type-synonym families, they really are ''functions'' as much as any value-level function is.  For example it would be silly to insist on a leading colon here:
    5843{{{
    59         data T (~>) = MkT (Int ~> Int)
     44  type family (+) :: * -> * -> *
     45  type instance Zero + n2 = n2
     46  type instance (Succ n1) + n2 = Succ (n1 + n2)
    6047}}}
    61 We'd have to use a type variable in back-quotes instead.
    62 
    63 == Observations ==
    6448
    6549 * Note that classes can be infix too; this is useful.
     
    7458 * Need to allow infix notation in contexts
    7559{{{
    76 f :: (a :>: b) => bla blah
     60f :: (a >> b) => bla blah
    7761}}}
    7862 * Watch out for code like this (http://hackage.haskell.org/trac/ghc/ticket/1727)
     
    8569}}}
    8670
     71== References ==
     72
     73 * [http://www.haskell.org/ghc/docs/latest/html/users_guide/type-extensions.html#infix-tycons  Infix type constructors, classes, and type variables] in the GHC User's Guide.
     74
     75== Tickets ==
     76[[TicketQuery(description~=InfixTypeConstructors)]]
     77
     78== Pros ==
     79 * This is a straightforward generalisation, and doesn't break any existing code (except code that uses GHC extensions to have a type variable that is an operator).
     80 * It's very useful to write type expressions like `(a + b)`.
     81
     82== Cons ==
     83
     84* 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.
     85{{{
     86        data T (~>) = MkT (Int ~> Int)
     87}}}
     88We'd have to use a type variable in back-quotes instead.
     89
     90