This is a continuation of what I wrote on the Haskell Prime mailing list which accounts for why this is the eighth in the series. These are lecture notes and if anyone has not already noticed from the Haskell Prime mailing list. I am giving a lecture.

Type aliases allow you to extend the type system beyond the capabilities of the language. For example, natural numbers are not part of the type system, but you can say that a number has the natural number type by using a type alias. Ensuring that a number is indeed a natural number is your problem. The compiler will only ensure that it is at least an integer. There are a variety of instances where type aliases are useful. A prominent application in computer programming languages is to establish a form verses function relationship. Types in functional languages are formal types and not functional types ironically.

A common example of this is to define an address type alias where you declare it as a string. Yes, it is a string formally, but it does not function as such. Its semantics are more specific and so it is not merely a string. How it behaves in context will differ and be more specific than a string. To quote Dune, "There is a place terrifying to us, women, that we cannot go." The compiler cannot go there, but it can verify that it is at least a string. The form verses function distinction is especially useful when unifying against a tuple. Functional types can in large measure supplant labels. When you know its functional type you will usually know enough to know what it is referring to. When all you know is its formal type it can be touch and go. It is possible as the programmer to develop a set of rules beyond those that ensure that the address type is a string that for the benefit of the programmer describe where it is grammatically correct for variables of the address type may appear to which the compiler is wholly ignorant.