<metaproperty="description"content="It should be noted that in the TL schema of the overwhelming majority of API calls the use of polymorphic types is restricted…">
<metaproperty="og:title"content="Polymorphism in TL">
<metaproperty="og:image"content="">
<metaproperty="og:description"content="It should be noted that in the TL schema of the overwhelming majority of API calls the use of polymorphic types is restricted…">
<divclass="dev_page_bread_crumbs"><ulclass="breadcrumb clearfix"><li><ahref="/mtproto">Mobile Protocol</a></li><iclass="icon icon-breadcrumb-divider"></i><li><ahref="/mtproto/TL">TL Language</a></li><iclass="icon icon-breadcrumb-divider"></i><li><ahref="/mtproto/TL-polymorph">Polymorphism in TL</a></li></ul></div>
<h1id="dev_page_title">Polymorphism in TL</h1>
<divid="dev_page_content"><p>It should be noted that in the TL schema of the overwhelming majority of API calls the use of polymorphic types is restricted to the Vector type. Nevertheless, having a view of the big picture is still helpful.</p>
<p>For example, let us consider the IntList, which is defined as follows:</p>
<pre><code>int_cons hd:int tl:IntList = IntList;
int_nil = IntList;</code></pre>
<p>The “int_cons” and “int_nil” constructors as well as the “IntList” type itself are expressions of the following types (writing A : X means that A is an expression of type X):</p>
<pre><code>IntList : Type;
int_cons : int -> IntList -> IntList;
int_nil : IntList;</code></pre>
<p>The keyword <em>Type</em> is used to denote the type of all types. Note that Type is not Object (Object is the type of all terms).
Here is alternative syntax that could be used in some other functional programming language (but not in TL):</p>
<p>TL supports the following version (curly brackets indicate optional fields, see below):</p>
<pre><code>cons {X:Type} hd:X tl:(List X) = List X;
nil {X:Type} = List X</code></pre>
<p>Here is an alternative formulation in other functional languages with dependent types:</p>
<pre><code>NewType List {X:Type} :=
| cons {X:Type} hd:X tl:(List X)
| nil {X:Type}
EndType</code></pre>
<p>In any event, these variations are equivalent to one another from the point of view of the formal theory of types and lead to the definition of the following terms:</p>
<pre><code>List : Type -> Type;
cons : forall (X:Type), X -> List X -> List X;
nil : forall (X:Type), X -> List X;</code></pre>
<p>In each case, remember that writing “A -> B” is shorthand for “forall (x : A), B” for any variable x not entering into A and B. For example, the “cons” type could be written as follows:</p>
<pre><code>cons : forall (X:Type), forall (hd : X), forall (tl : List X), List X</code></pre>
<p>or more compactly:</p>
<pre><code>cons : forall (X : Type) (hd : X) (tl : List X), List X</code></pre>
<p>See <ahref="https://en.wikipedia.org/wiki/Calculus_of_constructions">Calculus of constructions</a>. Examples of functional languages with dependent types, which support similar constructions are <ahref="https://en.wikipedia.org/wiki/Coq">Coq</a> and <ahref="https://en.wikipedia.org/wiki/Agda_%28programming_language%29">Agda</a>.</p>
<p>In this case, the entry after a universal quantifier proves to be more content-related than that after an arrow, because the name of a variable bound by the quantifier is used to transmit the name of the corresponding field in the constructor, even if this variable is not used anywhere as it pertains to the expression under the quantifier. Structurally, all of these entries of the “cons” type are equivalent.</p>
<h3><aclass="anchor"href="#serialization-of-types-values-of-type-type"id="serialization-of-types-values-of-type-type"name="serialization-of-types-values-of-type-type"><iclass="anchor-icon"></i></a>Serialization of types (values of type Type)</h3>
<p>As we can see, to serialize a value of type List X, which has been obtained by applying the combinator “cons X:Type hd:X tl:(List X) = List X”, we need to:</p>
<ol>
<li>serialize the name of the “cons” combinator into a 32-bit number;</li>
<li>serialize X (as a type, i.e. as a value of type Type) if X is a required parameter;</li>
<li>serialize the head of the list (hd) as a value of type X;</li>
<li>serialize the tail of the list as a value of the polymorphic type List X. </li>
<p>In the first step, the natural question is which string exactly will be used to calculate the CRC32. It is proposed to take "<code>cons X:Type hd:X tl:List X = List X</code>” without the terminating semicolon and without any parentheses (closed type expressions are unambiguously reconstructed based on their construction's prefix).</p>
<p>In the last step, we recursively resolve the very same problem of serializing a value of type List X; we will consider it resolved based on the assumption of induction in the construction of the value being serialized. We will similarly consider the third step understandable (induction in the construction of the value being serialized). </p>
<p>We still need to describe how to transmit (serialize) types, e.g. values of type <strong>Type</strong>. <em>Types in TL schemas currently appear only as constructors' optional parameters and are therefore never serialized explicitly. Rather, their values are inferred from the previously known type of the value being serialized</em>. </p>
<p>For completeness we will describe how it would be possible to serialize types (values of type Type). However, keep in mind that for now this information is not useful. See <ahref="/mtproto/TL-types">Type serialization</a>.</p>
<h3><aclass="anchor"href="#optional-arguments-in-polymorphic-constructors"id="optional-arguments-in-polymorphic-constructors"name="optional-arguments-in-polymorphic-constructors"><iclass="anchor-icon"></i></a>Optional arguments in polymorphic constructors</h3>
<p>It was stated above that any subset of (the first few) parameters of any constructor can be identified as optional (by enclosing their declarations in curly brackets), but this is not actually entirely accurate. First, these optional parameters can only be of type <code>Type</code> or <code>#</code> (natural numbers). Second, optional parameters must share the return value's type, otherwise their value cannot be determined.</p>
<p>Note that @'''constr-id''' means the constructor's “full form” (in which all optional parameters become required), while '''constr-id'' denotes its abbreviated form (without the optional arguments). If there are no optional arguments, then these two forms are the same. Constructors' full forms are never used at present.</p>
<p>There is a small problem: if we want to serialize the value of the bare type '%pair string int' or '%pair string Y' (which in TL is usually denoted simply as “pair”, though the form “%Pair” is preferable), we cannot simultaneously use both the full constructor @pair and the partial pair, because the constructor's name will not be serialized. Therefore, we must differentiate the bare types %@pair (type X, type Y, value x:X, and value y:Y are serialized) and %pair (only x:X and y:Y are serialized; types X and Y are known from the context). In practice, we nearly almost always need the bare type %pair, and this is precisely what “pair” means in the type's context in TL. Therefore, </p>
<pre><code>record name:string map:(List (pair int string)) = Record;</code></pre>
<p>will be serialized approximately like we want it to be (the serialization of list elements will consist of the serialization of int and the serialization of string, without any additional headers, types, or combinator names).
Incidentally, when calculating the “record” combinator's name <em>'record'</em> in the example given above, the CRC32 of <code>record name:string map:List pair int string = Record</code> will be computed.</p>
