1 files changed, 35 insertions, 0 deletions
diff --git a/miralib/manual/22 b/miralib/manual/22
new file mode 100644
index 0000000..b967d27
--- /dev/null
+++ b/miralib/manual/22
@@ -0,0 +1,35 @@
+_E_m_p_t_y_ _t_y_p_e_s (also called _P_l_a_c_e_h_o_l_d_e_r_ _t_y_p_e_s)
+
+An empty type has no values belonging to it (apart  from  the  undefined
+value,  undef,  which  is  a  member  of  every  type).  Empty types are
+declared as follows:
+
+	widget :: _t_y_p_e
+
+this declares `widget' to be a type but gives it no values.
+
+Empty types can be used during program development as  placeholders  for
+types  whose  representation  is not yet decided.  For example given the
+above declaration we can give type specifications involving widget, e.g.
+
+	foo :: num->widget->widget
+	gronk :: [widget]->widget
+
+and write code using `foo' and `gronk' which can  be  checked  for  type
+correctness.   At  a later stage the specification of widget as an empty
+type can be replaced by a non-empty type definition, using ==,  ::=,  or
+_a_b_s_t_y_p_e, allowing foo, gronk, to be defined.
+
+Typenames declared as empty can have any arity, eg
+	table * ** :: _t_y_p_e
+This creates a family of empty types, such as `table num  bool'  and  so
+on.  They are all devoid of values (apart from undef).  The general form
+of this kind of specification is
+	tform-list :: _t_y_p_e
+where `tform' consists of a typename followed by zero  or  more  generic
+type  variables  (and  it  is  permitted  to  declare several such types
+simultaneously, separated by commas, whence `tform-list').
+
+An empty type may be considered equivalent to an algebraic type with  no
+constructors.
+