<metaproperty="description"content="TL Language makes it possible to declare a combinator's first few parameters optional. Subsequently, they are almost never…">
<metaproperty="og:description"content="TL Language makes it possible to declare a combinator's first few parameters optional. Subsequently, they are almost never…">
<divid="dev_page_content"><p><ahref="TL">TL Language</a> makes it possible to declare a combinator's first few parameters optional. Subsequently, they are almost never required to be explicitly stated. This is directly related to another important property of TL: <ahref="TL-polymorph">polymorphism</a>.</p>
<p>The result type is known (for example, we're parsing the response to a previously sent RPC query and therefore know the value of some type is expected). In this case, the result type may be used to determine the values of the combinator's implicit parameters.</p>
<p>The result type is not known. It is determined as a result of (de)serialization (for example, we are serializing an RPC query). In this case, it is necessary to explicitly specify (and serialize) all of the combinator's optional parameters by using the full version of the combinator.</p>
<p>We will assume that the functional combinator only differs from the constructor in that before its result type the <code>!</code> modifier is implicitly added, and the (remote or local) computation of a functional expression may be presented as the execution of some polymorphic function <code>eval : !X -> X</code>.</p>
<p>Moreover, the unknown result type is obviously usually (but not always) bound to the serialization of an expression whose type has been modified by <code>!</code>.</p>
<p>We can formulate the following rules. Let there be some constructor</p>
<p>Some of its arguments or its result may be marked with the <code>!</code> modifier (We consider a functional combinator to be a constructor whose result type has been modified by an implicit <code>!</code>).</p>
<p>The following conditions must hold:</p>
<ul>
<li>
<p>Each type <em>T1</em>, ..., <em>Tm</em>, <em>U1</em>, ..., <em>Un</em>, and <em>T</em> may depend on parameters of type <code>Type</code> or <code>#</code>, which have been declared to the left of the use of the given type.</p>
</li>
<li>
<p>The types of implicit parameters <em>T1</em>, ..., <em>Tm</em> may not be modified by <code>!</code>.</p>
</li>
<li>
<p>Only implicit parameters of type <code>Type</code> or <code>#</code> are allowed. In other words, <em>Ti</em> is either a <code>Type</code> or a <code>#</code>. (Unlike the previous rule, this rule may be relaxed in the future.)</p>
</li>
<li>
<p>Each implicit parameter <em>a1</em>, ..., <em>am</em> must be used at least once -- either within one of the <em>Ui</em> types that have a <code>!</code>, or in the result type <em>T</em>, <em>if it does not have an explicit or implicit <code>!</code></em>. </p>
</li>
<li>
<p>If an implicit parameter <em>ai</em> is not used in the result type, or if the result type has a <code>!</code>, then its first (leftmost) usage must be within a type <em>Uj</em> that is modified by <code>!</code>.</p>
</li>
</ul>
<p>The idea is this: we assume that during (de)serialization of a value of a type modified by <code>!</code> that we do not know this type in advance and we will find out what it is only based on the result of the (de)serialization; Conversely, we assume that during (de)serialization of a value of a type that is not modified by <code>!</code> that we know this type in advance. In this case, complying with the rules stated above lets us always compute the values of all implicit parameters -- either from the (previously known) result type or from the type of one of the <code>bj:!Uj</code> parameters (which was obtained during the serialization process).</p>
<p>In fact, <code>!</code> denotes the direction in which type information is flowing. By default, the result type is the source of information about types (and their parameters), while argument types are the recipients of that information. The use of <code>!</code> reverses the direction of information flow, making the result type the recipient and the argument type the source of type information.</p>
<p>See also <ahref="TL-abstract-types">Binary serialization and abstract TL types</a> and <ahref="TL-polymorph">Polymorphism in TL</a>.</p></div>
</div>
</div>
</div>
<divclass="footer_wrap">
<divclass="footer_columns_wrap footer_desktop">
<divclass="footer_column footer_column_telegram">
<h5>Telegram</h5>
<divclass="footer_telegram_description"></div>
Telegram is a cloud-based mobile and desktop messaging app with a focus on security and speed.
