Page Menu
Home
Xreate
Search
Configure Global Search
Log In
Docs
Questions
Repository
Issues
Patches
Internal API
Files
F3999823
latetranscend.xml
No One
Temporary
Actions
Download File
Edit File
Delete File
View Transforms
Subscribe
Mute Notifications
Subscribers
None
File Metadata
Details
File Info
Storage
Attached
Created
Thu, Jul 9, 3:01 AM
Size
7 KB
Mime Type
text/xml
Expires
Sat, Jul 11, 3:01 AM (1 d, 6 h)
Engine
blob
Format
Raw Data
Handle
272802
Attached To
rXR Xreate
latetranscend.xml
View Options
<?xml version="1.0" encoding="UTF-8"?>
<chapter version="5.1" xmlns="http://docbook.org/ns/docbook"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xila="http://www.w3.org/2001/XInclude/local-attributes"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:trans="http://docbook.org/ns/transclusion"
xmlns:svg="http://www.w3.org/2000/svg"
xmlns:m="http://www.w3.org/1998/Math/MathML"
xmlns:html="http://www.w3.org/1999/xhtml"
xmlns:db="http://docbook.org/ns/docbook">
<title>Late Transcend</title>
<para>Transcend is a powerful tool and as a consequence it's computationally
inefficient. Well, expressiveness has its cost. That's the reason why it's
mostly suited only for a compile time where it shines unequivocally.
Obviously, at this stage compiler lacks dynamic part - the data that is
known for sure only during actual program execution. In other words, Early
Transcend reasons over <emphasis>weak</emphasis> data - set of facts
reflecting possible states and conditions the program could go through
during execution. Before that, there is no way to be sure what exactly is
going to happen, only set of possibilities is available. Nevertheless, in
many cases it's not enough and that's why <emphasis>Late
Transcend</emphasis> is introduced - reasoning and making decisions based on
data available at runtime.</para>
<para>Late Transcend approach can be described as having three
phases:</para>
<itemizedlist>
<listitem>
<para>Input: at compile time Transcend working with weak data produces
decisions for all possible alternatives. Generated set is used as an
input for Late Transcend. As it's unknown which exactly decision turns
out to be true, every decision has a <emphasis>guards</emphasis> - set
of pairs <emphasis>(variable, value)</emphasis> that describe exact
state for which it's possible to reach given decision.</para>
</listitem>
<listitem>
<para>Validation: A decision is considered to be valid only if all
guards are met, i.e. variables from guard pairs actually have required
values. In a sense Late Transcend decisions are deferred until
correspondent preconditions proved to be true.</para>
</listitem>
<listitem>
<para>Execution: DIfferent <emphasis>guarded</emphasis> decisions may
produce different code branches. All correspondent code branches are
compiled and present in the code in order to be used when needed. At
branching point guards are tested and appropriate branch is selected to
be executed next.</para>
</listitem>
</itemizedlist>
<section>
<title>Late Annotations and ASP Representation</title>
<para><emphasis>Late annotations</emphasis> is a particular type of
annotations that depend on parameters known only at runtime.
Example:</para>
<programlisting xml:id="LateAnn_1">name="tests/latetranscend.cpp: LateReasoning.Doc_SwitchLateOperation"
mul(a, b)::float; arithmetic(ArithmX)</programlisting>
<para>Suppose we have different specializations of <code>mul</code>
function each implementing different multiplication precision and it
controlled by using <code>arithmetic(fast)</code>,
<code>arithmetic(accurate)</code> and similar annotations. In this example
<code>arithmetic(ArithmX)</code> is a late annotation, if
<code>ArithmX</code> is a parameter known only during program
execution.</para>
<para>Currently, late annotations do not differ syntactically from other
annotations. Only if annotation is recognized to have late arguments it's
marked internally as a <emphasis>late</emphasis> and special rules of
conversion to ASP form apply.</para>
<para>Late annotation in ASP form is presented as follows:</para>
<synopsis>SYNTAX:
**late**(//target//, (//guard-identifiers-list//), (//guard-values-list//), //body//):- //parameter-types-list//. </synopsis>
<itemizedlist>
<listitem>
<para><emphasis>target</emphasis> References entity for which late
annotation is applicable</para>
</listitem>
<listitem>
<para><emphasis>guard-identifiers-list</emphasis> List of guard
identifiers</para>
</listitem>
<listitem>
<para>guard-values-list List of guard values</para>
</listitem>
</itemizedlist>
<itemizedlist>
<listitem>
<para><emphasis>body</emphasis> Decision deemed valid if guards are
met</para>
</listitem>
<listitem>
<para><emphasis>parameter-types-list</emphasis> List of types of late
parameters</para>
</listitem>
</itemizedlist>
<para>Meaning that a fact <code>body</code> wrapped by modifier
<code>late()</code> alongside with two lists: guards' identifiers and
guards' values.</para>
<para>For an example above, <code>arithmetic(ArithmX)</code> translated
into form below where exact references depend on a program:</para>
<programlisting xml:id="Output_LateAnn_1">late(s(0,-2,2), (s(1,-2,2)), (ArithmX), arithmetic(ArithmX)):- arithmetic(ArithmX).</programlisting>
<para>This rule generates different facts for each possible <code>x</code>
alternative. At runtime only those facts are selected whose guards are
met, i.e. referenced variables actually have specified values.</para>
</section>
<section>
<title>Switch Late Operation</title>
<synopsis>SYNTAX:
**switch late** ( //condition// [-> //alias// ] [:: //condition-type// [; //annotations-list//] ] ) :: //type// [; //annotations-list//]
//switch-block//</synopsis>
<itemizedlist>
<listitem>
<para><emphasis>condition</emphasis> switch's condition</para>
</listitem>
<listitem>
<para><emphasis>alias</emphasis> optional alias to denote condition's
result within internal code block annotations. If there is no alias
and condition is just one identifier it's accessible by its own
name</para>
</listitem>
<listitem>
<para>condition-type Condition must have slave type</para>
</listitem>
</itemizedlist>
<para>Switch Late operation allows to designate <emphasis>alias</emphasis>
as a <emphasis>late parameter</emphasis> to use in late annotation. It can
be conceptualised as lifting Brute value to Transcend level. During
compilation it generates different <emphasis>switch-block</emphasis>
branches for each possible condition value and only branch is executed
whose guard correspond condition. Example:</para>
<programlisting xml:id="SwitchLate_1">name="tests/latetranscend.cpp: LateReasoning.Doc_SwitchLateOperation"
ArithmeticT = type slave arithmetic.
test = function(a::float, b::float, ArithmX::ArithmeticT):: float; entry
{
switch late (ArithmX):: float
{
mul(a, b)::float; arithmetic(ArithmX)
}
}</programlisting>
<para>Compiler generates several branches for all possible
<code>arithmetic</code> variants. Only one branch executed depending on
<code>arithmX</code>.</para>
</section>
</chapter>
Event Timeline
Log In to Comment