Changes between Version 5 and Version 6 of InfixTypeConstructors

Timestamp:

10/09/08 00:55:53 (5 years ago)

Author:

simonpj@…

Comment:

--

InfixTypeConstructors

@@ -34 +34 @@
 (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").
 
+== Observations ==
 
-== References ==
-
- * [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.
-
-== Tickets ==
-[[TicketQuery(description~=InfixTypeConstructors)]]
-
-== 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.
+ * 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:
 {{{
-        data T (~>) = MkT (Int ~> Int)
+  type family (+) :: * -> * -> *
+  type instance Zero + n2 = n2
+  type instance (Succ n1) + n2 = Succ (n1 + n2)
 }}}
-We'd have to use a type variable in back-quotes instead.
-
-== Observations ==
 
  * Note that classes can be infix too; this is useful.
@@ -74 +58 @@
  * Need to allow infix notation in contexts
 {{{
-f :: (a :>: b) => bla blah
+f :: (a >> b) => bla blah
 }}}
  * Watch out for code like this (http://hackage.haskell.org/trac/ghc/ticket/1727)
@@ -85 +69 @@
 }}}
 
+== References ==
+
+ * [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.
+
+== Tickets ==
+[[TicketQuery(description~=InfixTypeConstructors)]]
+
+== Pros ==
+ * 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).
+ * It's very useful to write type expressions like `(a + b)`.
+
+== 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.
+
+