Changes between Version 5 and Version 6 of InfixTypeConstructors


Ignore:
Timestamp:
Oct 9, 2008 7:55:53 AM (6 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