![]() (And, indeed, one can derive that all order-0 functions are arity-0. and in the world where you allow yourself that flexibility, I think it is perfectly natural to talk about Int as being an order-0, arity-0 function. Using compile-time generics (which we just call generics) is similar to using types with type variables in Haskell. So, Bool -> Bool has order 1, (a -> b) -> -> has order 2 (and arity 2), ((Int -> r) -> r) -> Cont r Int has order 3. If you allow yourself that flexibility, then you can also talk more flexibly about order, so that the natural generalization of "order" is to count up how many times you can go to the left of an arrow before you are forced to bottom out at a non-arrow type. There's no problem with such definitions. The obvious generalization of arity is then to count up how many times you have to go to the right of an arrow before you get to a non-arrow type, so that a -> (b -> c) is arity 2, Bool -> Bool -> Bool -> Bool is arity 3, and Int is arity 0. Despite the fact that the -> type former is binary and so technically a function has one argument and one return type, I think it's nevertheless also useful to have a shorthand for talking and thinking about Haskell that allows you to mentally and verbally chunk a type like a -> (b -> c) as "a function with two arguments". Those beliefs are useful: they form the grounding of a very precise way to talk about Haskell and to understand the behavior of Haskell.īut they've always been a bit too strident for my taste.
0 Comments
Leave a Reply. |