+(*D
+
+Note that the field `S` was declared with `:>` instead of a simple `:`.
+This declares the `S` projection to be a coercion. A coercion is
+a function case the system automatically inserts when it is needed.
+In that case, the projection `S` has type `Ax → setoid`, and whenever
+the expected type of a term is `setoid` while its type is `Ax`, the
+system inserts the coercion around it, to make the whole term well types.
+
+When formalizing an algebraic structure, declaring the carrier as a
+coercion is a common practice, since it allows to write statements like
+
+ ∀G:Group.∀x:G.x * x^-1 = 1
+
+The quantification over `x` of type `G` is illtyped, since `G` is a term
+(of type `Group`) and thus not a type. Since the carrier projection
+`carr` of `G` is a coercion, that maps a `Group` into the type of
+its elements, the system automatically inserts `carr` around `G`,
+obtaining `…∀x: carr G.…`. Coercions are also hidden by the system
+when it displays a term.
+
+In this particular case, the coercion `S` allows to write
+
+ ∀A:Ax.∀a:A.…
+
+Since `A` is not a type, but it can be turned into a `setoid` by `S`
+and a `setoid` can be turned into a type by its `carr` projection, the
+composed coercion `carr ∘ S` is silently inserted.
+
+Implicit arguments
+------------------
+
+Something that is not still satisfactory, in that the dependent type
+of `I` and `C` are abstracted over the Axiom set. To obtain the
+precise type of a term, you can use the `ncheck` command as follows.
+
+D*)
+
+(* ncheck I. *)
+(* ncheck C. *)
+
+(*D
+
+One would like to write `I a` and not `I A a` under a context where
+`A` is an axiom set and `a` has type `S A` (or thanks to the coercion
+mecanism simply `A`). In Matita, a question mark represents an implicit
+argument, i.e. a missing piece of information the system is asked to
+infer. Matita performs some sort of type inference, thus writing
+`I ? a` is enough: since the second argument of `I` is typed by the
+first one, the first one can be inferred just computing the type of `a`.
+
+D*)
+
+(* ncheck (∀A:Ax.∀a:A.I ? a). *)
+
+(*D
+
+This is still not completely satisfactory, since you have always type
+`?`; to fix this minor issue we have to introduce the notational
+support built in Matita.
+
+Notation for I and C
+--------------------
+
+Matita is quipped with a quite complex notational support,
+allowing the user to define and use mathematical notations
+([From Notation to Semantics: There and Back Again][1]).
+
+Since notations are usually ambiguous (e.g. the frequent overloading of
+symbols) Matita distinguishes between the term level, the
+content level, and the presentation level, allowing multiple
+mappings between the contenet and the term level.
+
+The mapping between the presentation level (i.e. what is typed on the
+keyboard and what is displayed in the sequent window) and the content
+level is defined with the `notation` command. When followed by
+`>`, it defines an input (only) notation.
+
+D*)
+
+notation > "𝐈 term 90 a" non associative with precedence 70 for @{ 'I $a }.
+notation > "𝐂 term 90 a term 90 i" non associative with precedence 70 for @{ 'C $a $i }.
+
+(*D
+
+The forst notation defines the writing `𝐈 a` where `a` is a generic
+term of precedence 90, the maximum one. This high precedence forces
+parentheses around any term of a lower precedence. For example `𝐈 x`
+would be accepted, since identifiers have precedence 90, but
+`𝐈 f x` would be interpreted as `(𝐈 f) x`. In the latter case, parentheses
+have to be put around `f x`, thus the accepted writing would be `𝐈 (f x)`.
+
+To obtain the `𝐈` is enough to type `I` and then cycle between its
+similar symbols with ALT-L. The same for `𝐂`. Notations cannot use
+regular letters or the round parentheses, thus their variants (like the
+bold ones) have to be used.
+
+The first notation associates `𝐈 a` with `'I $a` where `'I` is a
+new content element to which a term `$a` is passed.
+
+Content elements have to be interpreted, and possibly multiple,
+incompatible, interpretations can be defined.
+
+D*)
+
+interpretation "I" 'I a = (I ? a).
+interpretation "C" 'C a i = (C ? a i).
+
+(*D
+
+The `interpretation` command allows to define the mapping between
+the content level and the terms level. Here we associate the `I` and
+`C` projections of the Axiom set record, where the Axiom set is an implicit
+argument `?` to be inferred by the system.
+
+Interpretation are bi-directional, thus when displaying a term like
+`C _ a i`, the system looks for a presentation for the content element
+`'C a i`.
+
+D*)
+
+notation < "𝐈 \sub( ❨a❩ )" non associative with precedence 70 for @{ 'I $a }.
+notation < "𝐂 \sub( ❨a,\emsp i❩ )" non associative with precedence 70 for @{ 'C $a $i }.
+
+(*D
+
+For output purposes we can define more complex notations, for example
+we can put bold parenteses around the arguments of `𝐈` and `𝐂`, decreasing
+the size of the arguments and lowering their baseline (i.e. putting them
+as subscript), separating them with a comma followed by a little space.
+
+The first (technical) definition
+--------------------------------
+
+Before defining the cover relation as an inductive predicate, one
+has to notice that the infinity rule uses, in its hypotheses, the
+cover relation between two subsets, while the inductive predicate
+we are going to define relates an element and a subset.
+
+An option would be to unfold the definition of cover between subsets,
+but we prefer to define the abstract notion of cover between subsets
+(so that we can attach a (ambiguous) notation to it).
+
+Anyway, to ease the understaing of the definition of the cover relation
+between subsets, we first define the inductive predicate unfolding the
+definition, and we later refine it with.
+
+D*)
+
+ninductive xcover (A : Ax) (U : Ω^A) : A → CProp[0] ≝
+| xcreflexivity : ∀a:A. a ∈ U → xcover A U a
+| xcinfinity : ∀a:A.∀i:𝐈 a. (∀y.y ∈ 𝐂 a i → xcover A U y) → xcover A U a.
+
+(*D
+
+We defined the xcover (x will be removed in the final version of the
+definition) as an inductive predicate. The arity of the inductive
+predicate has to be carefully analyzed:
+
+> (A : Ax) (U : Ω^A) : A → CProp[0]
+
+The syntax separates with `:` abstractions that are fixed for every
+constructor (introduction rule) and abstractions that can change. In that
+case the parameter `U` is abstracted once and forall in front of every
+constructor, and every occurrence of the inductive predicate is applied to
+`U` in a consistent way. Arguments abstracted on the right of `:` are not
+constant, for example the xcinfinity constructor introduces `a ◃ U`,
+but under the assumption that (for every y) `y ◃ U`. In that rule, the left
+had side of the predicate changes, thus it has to be abstrated (in the arity
+of the inductive predicate) on the right of `:`.
+
+D*)
+
+(* ncheck xcreflexivity. *)
+
+(*D
+
+We want now to abstract out `(∀y.y ∈ 𝐂 a i → xcover A U y)` and define
+a notion `cover_set` to which a notation `𝐂 a i ◃ U` can be attached.
+
+This notion has to be abstracted over the cover relation (whose
+type is the arity of the inductive `xcover` predicate just defined).
+
+Then it has to be abstracted over the arguments of that cover relation,
+i.e. the axiom set and the set U, and the subset (in that case `𝐂 a i`)
+sitting on the left hand side of `◃`.
+
+D*)
+
+ndefinition cover_set :
+ ∀cover: ∀A:Ax.Ω^A → A → CProp[0]. ∀A:Ax.∀C,U:Ω^A. CProp[0]
+≝
+ λcover. λA, C,U. ∀y.y ∈ C → cover A U y.
+
+(*D
+
+The `ndefinition` command takes a name, a type and body (of that type).
+The type can be omitted, and in that case it is inferred by the system.
+If the type is given, the system uses it to infer implicit arguments
+of the body. In that case all types are left implicit in the body.
+
+We now define the notation `a ◃ b`. Here the keywork `hvbox`
+and `break` tell the system how to wrap text when it does not
+fit the screen (they can be safely ignore for the scope of
+this tutorial). we also add an interpretation for that notation,
+where the (abstracted) cover relation is implicit. The system
+will not be able to infer it from the other arguments `C` and `U`
+and will thus prompt the user for it. This is also why we named this
+interpretation `covers set temp`: we will later define another
+interpretation in which the cover relation is the one we are going to
+define.
+
+D*)