+import GHC.Exts( IsString(..) )
+
+newtype MyString = MyString String deriving (Eq, Show)
+instance IsString MyString where
+ fromString = MyString
+
+greet :: MyString -> MyString
+greet "hello" = "world"
+greet other = other
+
+main = do
+ print $ greet "hello"
+ print $ greet "fool"
+</programlisting>
+</para>
+<para>
+Note that deriving <literal>Eq</literal> is necessary for the pattern matching
+to work since it gets translated into an equality comparison.
+</para>
+</sect2>
+
+</sect1>
+
+<sect1 id="type-families">
+<title>Type families</title>
+
+<para>
+ <firstterm>Indexed type families</firstterm> are a new GHC extension to
+ facilitate type-level
+ programming. Type families are a generalisation of <firstterm>associated
+ data types</firstterm>
+ (“<ulink url="http://www.cse.unsw.edu.au/~chak/papers/CKPM05.html">Associated
+ Types with Class</ulink>”, M. Chakravarty, G. Keller, S. Peyton Jones,
+ and S. Marlow. In Proceedings of “The 32nd Annual ACM SIGPLAN-SIGACT
+ Symposium on Principles of Programming Languages (POPL'05)”, pages
+ 1-13, ACM Press, 2005) and <firstterm>associated type synonyms</firstterm>
+ (“<ulink url="http://www.cse.unsw.edu.au/~chak/papers/CKP05.html">Type
+ Associated Type Synonyms</ulink>”. M. Chakravarty, G. Keller, and
+ S. Peyton Jones.
+ In Proceedings of “The Tenth ACM SIGPLAN International Conference on
+ Functional Programming”, ACM Press, pages 241-253, 2005). Type families
+ themselves are described in the paper “<ulink
+ url="http://www.cse.unsw.edu.au/~chak/papers/SPCS08.html">Type
+ Checking with Open Type Functions</ulink>”, T. Schrijvers,
+ S. Peyton-Jones,
+ M. Chakravarty, and M. Sulzmann, in Proceedings of “ICFP 2008: The
+ 13th ACM SIGPLAN International Conference on Functional
+ Programming”, ACM Press, pages 51-62, 2008. Type families
+ essentially provide type-indexed data types and named functions on types,
+ which are useful for generic programming and highly parameterised library
+ interfaces as well as interfaces with enhanced static information, much like
+ dependent types. They might also be regarded as an alternative to functional
+ dependencies, but provide a more functional style of type-level programming
+ than the relational style of functional dependencies.
+</para>
+<para>
+ Indexed type families, or type families for short, are type constructors that
+ represent sets of types. Set members are denoted by supplying the type family
+ constructor with type parameters, which are called <firstterm>type
+ indices</firstterm>. The
+ difference between vanilla parametrised type constructors and family
+ constructors is much like between parametrically polymorphic functions and
+ (ad-hoc polymorphic) methods of type classes. Parametric polymorphic functions
+ behave the same at all type instances, whereas class methods can change their
+ behaviour in dependence on the class type parameters. Similarly, vanilla type
+ constructors imply the same data representation for all type instances, but
+ family constructors can have varying representation types for varying type
+ indices.
+</para>
+<para>
+ Indexed type families come in two flavours: <firstterm>data
+ families</firstterm> and <firstterm>type synonym
+ families</firstterm>. They are the indexed family variants of algebraic
+ data types and type synonyms, respectively. The instances of data families
+ can be data types and newtypes.
+</para>
+<para>
+ Type families are enabled by the flag <option>-XTypeFamilies</option>.
+ Additional information on the use of type families in GHC is available on
+ <ulink url="http://www.haskell.org/haskellwiki/GHC/Indexed_types">the
+ Haskell wiki page on type families</ulink>.
+</para>
+
+<sect2 id="data-families">
+ <title>Data families</title>
+
+ <para>
+ Data families appear in two flavours: (1) they can be defined on the
+ toplevel
+ or (2) they can appear inside type classes (in which case they are known as
+ associated types). The former is the more general variant, as it lacks the
+ requirement for the type-indexes to coincide with the class
+ parameters. However, the latter can lead to more clearly structured code and
+ compiler warnings if some type instances were - possibly accidentally -
+ omitted. In the following, we always discuss the general toplevel form first
+ and then cover the additional constraints placed on associated types.
+ </para>
+
+ <sect3 id="data-family-declarations">
+ <title>Data family declarations</title>
+
+ <para>
+ Indexed data families are introduced by a signature, such as