Files F4820858

polymorphism.xml
No OneTemporary
Actions

File Metadata

Created
Mon, Aug 24, 9:35 AM

polymorphism.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">
<?xxe-sn 26n42fz1reo 1?>
<title><?xxe-sn 26n42fz1reo 2?>Polymorphism</title>
<para><?xxe-sn 26n42fz1reo 3?><emphasis><?xxe-sn 26n42fz1reo 4?>Polymorphism</emphasis>
is an umbrella term to denote number of techniques across different
programing paradigms. They all share the same intention to provide ability
easily recombine software components in a different way with as little as
possible manual work on developer's side. It serves two major goals:
<emphasis><?xxe-sn 26n42fz1reo 5?>specialization</emphasis>, when software,
initially designed to support wide range of use cases, is configured for
concrete particular case and <emphasis><?xxe-sn 26n42fz1reo 6?>extension</emphasis>
- adapting software to an environment and conditions it was not specifically
designed for.</para>
<para><?xxe-sn 26n42fz1reo 7?>In course of software engineering evolution,
number of polymorphism techniques was proposed and experimented with, all
suited for different use-cases. Xreate presents generalized and elegant
approach that exhaustively covers wide landscape of polymorphism
variations.</para>
<para><?xxe-sn 26n42fz1reo 8?>Polymorphism in Xreate can be applied on two
levels:</para>
<itemizedlist>
<?xxe-sn 26n42fz1reo 9?>
<listitem>
<?xxe-sn 26n42fz1reo a?>
<para><?xxe-sn 26n42fz1reo b?><emphasis><?xxe-sn 26n42fz1reo c?>Functions
level</emphasis>. Function in Xreate can have a multiple
<emphasis><?xxe-sn 26n42fz1reo d?>specializations</emphasis> and
polymorphism is compiler's ability to decide which exactly
specialization to use depending on various factors</para>
</listitem>
<listitem>
<?xxe-sn 26n42fz1reo e?>
<para><?xxe-sn 26n42fz1reo f?><emphasis><?xxe-sn 26n42fz1reo g?>Modules
level</emphasis>. Multiple modules can provide the same service for
users. <link
xlink:href="/w/syntax/modules/#modules-resolution"><?xxe-sn 26n42fz1reo h?>Modules
Resolution</link> is a process to decide which exactly module to
use</para>
</listitem>
</itemizedlist>
<section>
<?xxe-sn 26n42fz1reo i?>
<title><?xxe-sn 26n42fz1reo j?>Function Level Polymorphism</title>
<para><?xxe-sn 26n42fz1reo k?>Basic idea is to allow developer to define
several functions with the same name or, in other words, several
<emphasis><?xxe-sn 26n42fz1reo l?>specializations</emphasis>. Caller code
then invokes necessary function by its shared name but can't directly
specify particular specialization. Exact specialization to be invoked is
decided later by decision process called <emphasis><?xxe-sn 26n42fz1reo m?>polymorphism
resolution</emphasis> carried out by Transcend. This indirect invocation
approach gives enough flexibility to use or replace different
specializations depending on various conditions during compile time as
well as at runtime.</para>
<para><?xxe-sn 26n42fz1reo n?>Please refer to <link
xlink:href="/w/syntax#function-specializations"><?xxe-sn 26n42fz1reo o?>syntax</link>
for details about function specializations. Each specialization must have
unique <emphasis><?xxe-sn 26n42fz1reo p?>guard</emphasis>(among all
specializations with the same name) to be discernible from others. To
summarize, function invocation is a two layered process, in which client
code specifies callee function's shared name, and polymorphism resolution
specifies specialization guard if needed.</para>
<para><?xxe-sn 26n42fz1reo q?>For an example, assume that we develop
program to operate under specified time constraints. To model
implementation suitable for real time environment, one specialization of
<code><?xxe-sn 26n42fz1reo r?>crucialOperation</code> is defined with
<code><?xxe-sn 26n42fz1reo s?>env(realtime)</code> guard i.e. satisfies
some fixed execution time constraints. Caller <code><?xxe-sn 26n42fz1reo t?>main</code>
specifies only function name <code><?xxe-sn 26n42fz1reo u?>crucialOperation</code>
thus delegating decision on guard to a polymorphism resolution done
elsewhere, based on environment's constraints the code is executed
in.</para>
<programlisting xml:id="FnLvlPoly_1"><?xxe-sn 26n42fz1reo v?>guard:: env(realtime)
{
crucialOperation = function:: int
{ 0 }
}
main = function:: int; entry
{
crucialOperation()
} </programlisting>
</section>
<section>
<?xxe-sn 26n42fz1reo w?>
<title><?xxe-sn 26n42fz1reo x?>Polymorphism Resolution</title>
<synopsis><?xxe-sn 26n42fz1reo y?>SYNTAX:
**dfa_callguard**(//call-site-ref//, //guard//)</synopsis>
<itemizedlist>
<?xxe-sn 26n42fz1reo z?>
<listitem>
<?xxe-sn 26n42fz1reo 10?>
<para><?xxe-sn 26n42fz1reo 11?><emphasis><?xxe-sn 26n42fz1reo 12?>call-site-ref</emphasis>
reference to a call site in AST</para>
</listitem>
<listitem>
<?xxe-sn 26n42fz1reo 13?>
<para><?xxe-sn 26n42fz1reo 14?><emphasis><?xxe-sn 26n42fz1reo 15?>guard</emphasis>
resolved function specialization guard</para>
</listitem>
</itemizedlist>
<para><?xxe-sn 26n42fz1reo 16?>When compiler encounters function
invocation that has several specialization it refers to the table
<code><?xxe-sn 26n42fz1reo 17?>dfa_callguard</code> to find out which
specialization to call. It must have entry with appropriate
<code><?xxe-sn 26n42fz1reo 18?>guard</code> for every invocation site
<code><?xxe-sn 26n42fz1reo 19?>call-site-ref</code> of a polymorphic
function. Polymorphism resolution is a process of filling out
<code><?xxe-sn 26n42fz1reo 1a?>dfa_callguard</code> for a compiler based
on custom Transcend rules reflecting one or another polymorphism
strategy.</para>
</section>
<section>
<?xxe-sn 26n42fz1reo 1b?>
<title><?xxe-sn 26n42fz1reo 1c?>Late Polymorphism</title>
<para><?xxe-sn 26n42fz1reo 1d?>Late Polymorphism is an extension to allow
polymorphism resolution to be based on data known only at runtime, i.e.
resolve function specializations dynamically. The Idea is to use Late
Transcend to access runtime data. See <link
xlink:href="/w/transcend/latetranscend"><?xxe-sn 26n42fz1reo 1e?>Late
Transcend</link> for details.</para>
<para><?xxe-sn 26n42fz1reo 1f?>Example below demonstrates <code><?xxe-sn 26n42fz1reo 1g?>test</code>
invoking polymorphic function <code><?xxe-sn 26n42fz1reo 1h?>compute</code>:</para>
<programlisting xml:id="LatePoly_1"><?xxe-sn 26n42fz1reo 1i?>Strategy = type variant {fast, precise}.
guard:: fast
{
compute = function:: int
{0}
}
guard:: precise
{
compute = function:: int
{1}
}
test = function(s:: Strategy; alias(strategy)):: int; entry
{
switch late (s):: int
{
compute():: int; guardalias(strategy)
}
}</programlisting>
<para><?xxe-sn 26n42fz1reo 1j?>Function <code><?xxe-sn 26n42fz1reo 1k?>compute</code>
has two specializations, <code><?xxe-sn 26n42fz1reo 1l?>fast</code> and
<code><?xxe-sn 26n42fz1reo 1m?>precise</code>. We see that <code><?xxe-sn 26n42fz1reo 1n?>test</code>
gets parameter <code><?xxe-sn 26n42fz1reo 1o?>s</code> that dictates exact
strategy to use. Clearly, resolution should work dynamically to cope with
cases like this, for value of parameter <code><?xxe-sn 26n42fz1reo 1p?>s</code>
not only is unknown at compile time, but it can change with each
<code><?xxe-sn 26n42fz1reo 1q?>test</code> execution.</para>
<para><?xxe-sn 26n42fz1reo 1r?>Operation Switch Late is compiled into
several branches, two in this case, each branch executing appropriate
<code><?xxe-sn 26n42fz1reo 1s?>compute</code> specialization. Correct
branch executed depending on current <code><?xxe-sn 26n42fz1reo 1t?>s</code>
value. Custom annotations <code><?xxe-sn 26n42fz1reo 1u?>alias(Alias)</code>
and <code><?xxe-sn 26n42fz1reo 1v?>guardalias(Alias)</code> used to assign
an alias in order to specify which parameter to use for as basis for
resolution</para>
</section>
<section>
<?xxe-sn 26n42fz1reo 1w?>
<title><?xxe-sn 26n42fz1reo 1x?>Auto Expansion of Late Parameters</title>
<para><?xxe-sn 26n42fz1reo 1y?>In previous example, switch late operation
was used to facilitate calling of polymorphic function with late
polymorphism resolution. It's not that convenient to wrap each invocation
by switch late whenever there is need to call late polymorphic function.
Specifically to handle cases like this, compiler uses late parameter auto
expansion technique.</para>
<para><?xxe-sn 26n42fz1reo 1z?>If compiler discovers that <code><?xxe-sn 26n42fz1reo 20?>late(dfa_callguard())</code>
entry exists for current invocation and it does not have enclosing switch
late already, compiler automatically generates different branches that
invoke relevant specializations and transfers control to a branch
depending on late parameter value. In other words invocation implicitly
wrapped into switch late instruction if needed.</para>
</section>
</chapter>
<?xxe-revisions
#1 2018-12-12T21:49:13Z pgess
?>

Event Timeline

Email: pr.h7@xreate.org · 2019 Xreate.org · Powered by Phabricator