Files F2747710

index.xml
No OneTemporary
Actions

File Metadata

Created
Sun, Apr 19, 3:35 AM

index.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 2b06cb2u4g0 1?>
<title><?xxe-sn 2b06cb2u4g0 2?>Xreate Manual</title>
<para><?xxe-sn 2b06cb2u4g0 6?>Xreate is an open source general purpose high
level programming language designed to write efficient and safe computer
programs.</para>
<para><?xxe-sn 2b06cb2u4g0 8?>Here "high level" is all about a developer
oriented side focused on an ability to easily write, read, reuse, as well as
adapt software to a constantly changing environment or business goals. In
this respect, any software product can be evaluated on the basis of three
dimensions: efficiency, safety, and flexibility. Unfortunately, those
properties are proved to be largely contradictory, for it is manageable to
write either efficient (yet unsafe) or safe (yet impractical) code, but not
both. Thus, the ultimate goal of the language is to allow developers to
produce code that would have all these properties at the same time. Blending
features of seemingly incompatible programming paradigms is a basis of
Xreate's design principles.</para>
<para><?xxe-sn 2b06cb2u4g0 7?>To achieve the aforementioned design goals,
Xreate consists of three distinctive layers:</para>
<itemizedlist>
<?xxe-sn 2b06cb2u4g0 e?>
<listitem>
<?xxe-sn 2b06cb2u4g0 f?>
<para><?xxe-sn 2b06cb2u4g0 g?><link xlink:href="/d/syntax/"><?xxe-sn 2b06cb2u4g0 o?>Brute</link>.
The lowest layer is called <emphasis><?xxe-sn 2b06cb2u4g0 p?>Brute
</emphasis>— this is code that is intended to be actually compiled. Code
on this level implements actual software functionality. It resembles the
usual imperative languages' apparatus and consists of executable
instructions such as arithmetic, branching, input / output, etc.</para>
</listitem>
<listitem>
<?xxe-sn 2b06cb2u4g0 i?>
<para><?xxe-sn 2b06cb2u4g0 j?><link xlink:href="/d/transcend/"><?xxe-sn 2b06cb2u4g0 q?>Transcend</link>.
Brute alone is not enough to constitute a full-fledged language since
code requires various non-executable metadata to express developer's
intents, check correctness, validity and perform other types of
analyses. In Xreate everything of this sort belongs to a declarative
type layer called <emphasis><?xxe-sn 2b06cb2u4g0 s?>Transcend</emphasis>.
Transcend is a logic reasoner that is appropriate to do management-type
work — it analyzes, oversees and controls Brute by guiding compilation
process. More precisely, everything on this level, logic or transcend
facts and rules, is gathered and sent to an external logic solver to
make solutions that are brought back in order to guide compilation.
Unlike usual static analysis tools, Transcend directly controls
compilation(see <link xlink:href="#basic-example"><?xxe-sn 2dc49lhpp1c 4?>Basic
Example</link>) and able to make decisions even based on data available
only at runtime(see <link
xlink:href="/d/transcend/late-transcend/"><?xxe-sn 2dc49lhpp1c 5?>Late
Transcend</link>)</para>
</listitem>
<listitem>
<?xxe-sn 2b06cb2u4g0 l?>
<para><?xxe-sn 2b06cb2u4g0 m?><link
xlink:href="/d/concepts/interpretation/"><?xxe-sn 2b06cb2u4g0 r?>Interpretation</link>.
There is also <emphasis><?xxe-sn 2b06cb2u4g0 t?>Interpretation</emphasis>
— the intermediate level resembling dynamically typed languages that is
used as a contact point and interpreter between Brute and
Transcend.</para>
</listitem>
</itemizedlist>
<para><?xxe-sn 2b06cb2u4g0 u?>On a syntactic level, Xreate is a procedural
language with extensive use of <emphasis><?xxe-sn 2b06cb2u4g0 v?><link
xlink:href="/d/transcend/"><?xxe-sn 2b06cb2u4g0 w?>annotations</link></emphasis>
— arbitrary unconstrained metadata that a software developer can attach to
different language constructs, variables and code blocks. Annotations are
completely invisible for the compiler proper and used by Transcend more as a
suggestion conveying additional information.</para>
<remark><?xxe-sn 2ccp2iy80zj 1td6aqezxvj7l?>"a different language
constructs": если подразумевается "конструкции разных языков", тогда лучше
"different languages' constructs". Если конструкции языка, в целом, то тогда
артикль a не нужен</remark>
<para><?xxe-sn 2da0r0b6680 2?>There are several extensions already
implemented to give a feeling what does this structure can be used for.
<link xlink:href="/d/concepts/containers/"><?xxe-sn 2da0r0b6680 3?>Containers</link>
chapter describes that it is possible to reason about and automatically
choose the most appropriate data structure's implementation depending on how
it is used in the code. Look at the example below:</para>
<programlisting><?xxe-sn 2da0r0b6680 4?>x = [1, 2, 3]:: [int].</programlisting>
<para><?xxe-sn 2da0r0b6680 5?>Container <code><?xxe-sn 2da0r0b6680 6?>x</code>
does not have well defined implementation just yet. Only by looking how it
is used throughout the code, the compiler is able to decide how exactly to
store container's data.</para>
<para><?xxe-sn 2da0r0b6680 7?>Interaction of different components and joint
use of external resources is covered by <link
xlink:href="/d/exploitation/"><?xxe-sn 2da0r0b6680 8?>Exploitation</link>:</para>
<programlisting><?xxe-sn 2da0r0b6680 9?>logger = createFileLogger("/some/file"):: Logger.
...
write(logger, "First log entry").
...
write(logger, "Last log entry").</programlisting>
<para><?xxe-sn 2da0r0b6680 a?>Exploitation reasoning allows to determine
when it is the <emphasis><?xxe-sn 2dc0uidlnnk 1?>first</emphasis>,
<emphasis><?xxe-sn 2dc0uidlnnk 2?>last</emphasis> access to resources such
as files, in other words, it infers access order. As a result it is possible
to automatically initialize / destruct related resources. Unlike RAII, an
another related technique, Exploitation is reserved to manage resources
usage that spans across different parts of a program: modules, plugins,
etc.</para>
<para><?xxe-sn 2dc0uidlnnk 8?><link
xlink:href="/d/virtualization/"><?xxe-sn 2dc0uidlnnk 4?>Virtualization</link>
reasoning also helps to work with external resources by enabling access
control <emphasis><?xxe-sn 2dc0uidlnnk 5?>if and when it is needed
only</emphasis>. Example:</para>
<programlisting><?xxe-sn 2dc0uidlnnk 6?>openFile("/some/file"):: string; assign_sizo(zoneA).
openFile("/some/file"):: string; assign_sizo(zoneB).</programlisting>
<para><?xxe-sn 2dc0uidlnnk 7?>If the compiler recognizes file access from
the different zones, as in this example, it applies an appropriate
virtualization strategy enough to ensure that instructions that belong to
different zones do not interfere with each other.</para>
<para><?xxe-sn 2cdtco54w00 3?>Unlike "pure", academic languages, Xreate
targets safe and reliable usage of effectful computations such as IO that is
covered above as well as mutable structures described in the <link
xlink:href="/d/communication/"><?xxe-sn 2b3f3osfk74 l?>Communication</link>
chapter.</para>
<para><?xxe-sn 2dc49lhpp1c 2?>Note, that the described extensions are not
part of the compiler and developers can write their own custom transcend
rules to cover other aspects.</para>
<section>
<?xxe-sn 2b06cb2u4g0 3?>
<title><?xxe-sn 2b06cb2u4g0 4?>Basic Example</title>
<para><?xxe-sn 2b06cb2u4g0 5?>To demonstrate what Xreate is all about,
basic example is given below:</para>
<programlisting xml:id="Example_1"><?xxe-sn 2b06cb2u4g0 x?>name="tests/introduction.cpp: Introduction.Doc_Example_1", lines=15
guard:: iAmVeryFast
{
div = function(a:: int, b:: int):: int
{
a / b
}
}
guard:: iAmVerySafe
{
div = function(a:: int, b:: int):: int
{
if ( b == 0 ):: int { zeroDivisionErrCode() } else { a / b }
}
}
test = function:: int; entry; iAmVerySecure
{
div(10, 5)
}</programlisting>
<para><?xxe-sn 2b06cb2u4g0 y?>Here entry point of the program is a
function <code><?xxe-sn 2b06cb2u4g0 z?>test</code> recognized so by the
compiler because of annotation <code><?xxe-sn 2b06cb2u4g0 10?>entry</code>
in its signature. There are also two functions with the same name
<code><?xxe-sn 2b06cb2u4g0 11?>div</code> called <emphasis><?xxe-sn 2b06cb2u4g0 12?>specializations</emphasis>.
Each specialization has a guard that defines a <emphasis><?xxe-sn 2dc49lhpp1c 1?>condition</emphasis>
that has to be met in order to invoke this particular specialization. In
the example, specializations of <code><?xxe-sn 2b06cb2u4g0 13?>div</code>
have <code><?xxe-sn 2b06cb2u4g0 14?>iAmVeryFast</code> and <code><?xxe-sn 2b06cb2u4g0 15?>iAmVerySafe</code>
guards, respectively. Let's say that a code author writes two
specializations where the first one is a very fast division
implementation, while the second one is a very safe division
implementation since it checks division by zero, being "unacceptably slow"
due to an extra check instruction, though. This is a basis of <link
xlink:href="/d/concepts/polymorphism/"><?xxe-sn 2b3f3osfk74 2?>polymorphism</link>
— client's code <code><?xxe-sn 2b3f3osfk74 3?>test</code> is able to work
with any specialization, and the compiler must decide which one to invoke
with the only hint it has — annotation <code><?xxe-sn 2b3f3osfk74 5?>iAmVerySecure</code>
in the function <code><?xxe-sn 2b3f3osfk74 7?>test</code>'s
signature.</para>
<remark><?xxe-sn 2ccp2iy80zj 1td6aqezxvj7n?>"provides two specializations"
- возможно, лучший вариант "designates/assigns/allocates two
specializations". Или даже просто specifies/indicates. (PS заменил на
specifies)</remark>
<remark><?xxe-sn 2ccp2iy80zj 1td6aqezxvj7m?>"unbearably slow" - я бы
заменил на более нейтральное "too slow". Unbearable - это скорее об
ощущениях человека. Или, если под "unbearably" имеется в виду "недопустимо
медленный", тогда - unacceptably slow.</remark>
<note>
<?xxe-sn 2b3f3osfk74 n?>
<para><?xxe-sn 2b3f3osfk74 o?>All annotations (except <code><?xxe-sn 2b3f3osfk74 m?>entry</code>)
are custom defined by developer itself.</para>
</note>
<para><?xxe-sn 2b3f3osfk74 6?>This is when Transcend comes into play. By
adding a transcend rule as shown below it is possible to associate
annotation <code><?xxe-sn 2b3f3osfk74 8?>iAmVerySecure</code> with
invocation of specialization guarded by <code><?xxe-sn 2b3f3osfk74 9?>iAmVerySafe:</code></para>
<programlisting xml:id="Transcend_Example_1"><?xxe-sn 2b3f3osfk74 a?>name="tests/introduction.cpp: Introduction.Doc_Example_1", lines=15
dfa_callguard(SiteInv, iAmVerySafe):-
dfa_callfn(SiteInv, div);
SiteInv = s(_, _, ScopeInv);
cfa_parent(ScopeInv, function(FnInv));
bind_func(FnInv, iAmVerySecure).</programlisting>
<para><?xxe-sn 2b3f3osfk74 b?>Transcend rules are written in ASP syntax —
common syntax to write logic programs. This particular rule reads that for
any function annotated with <code><?xxe-sn 2b3f3osfk74 c?>iAmVerySecure</code>,
certain specialization <code><?xxe-sn 2b3f3osfk74 d?>iAmVerySafe</code> is
chosen for <code><?xxe-sn 2b3f3osfk74 e?>div</code> invocation.</para>
<note>
<?xxe-sn 2b3f3osfk74 p?>
<para><?xxe-sn 2b3f3osfk74 q?>In this example an appropriate
specialization is statically resolved, so the other specialization isn't
even compiled.</para>
<remark><?xxe-sn 2ccp2iy80zj 1td6aqezxvj7o?>the, потому что их всего
две.</remark>
</note>
<para><?xxe-sn 2b3f3osfk74 f?>By providing custom rules it is possible to
implement any polymorphism strategy, be it performed statically or
dynamically. The example demonstrates basic workflow: Transcend gathers
available information about a program such as annotations and using custom
rules makes a decision to guide compilation process, particularly by
selecting appropriate specializations as in the above example.</para>
</section>
<section>
<?xxe-sn 2fchdmt7vgg 1?>
<title><?xxe-sn 2fchdmt7vgg 2?>More Advanced Example</title>
<para><?xxe-sn 2fchdmt7vgg 3?>Suppose we write a program to generate a web
page consisting of several blocks(e.g. a header, a footer) constructed
independently by different parts of our program. In order to organise the
code, we express our <emphasis><?xxe-sn 2fs1xxghz93 -wunr7fl0rw8v?>intention</emphasis>
that all blocks should be sent to a client in a very specific order: first
a header, then a body and footer, as below:</para>
<programlisting xml:id="ExampleEov_1_Expectation"><?xxe-sn 2fchdmt7vgg 4?>name="tests/exploitation.cpp: Exploitation.Doc_ExampleEov_1", lines=15
eov_expect(
webpage, header, body; %we expect body to be sent after header
webpage, body, footer %.. and footer after body
).</programlisting>
<para><?xxe-sn 2fchdmt7vgg 5?>This is similar to <link
xlink:href="/d/exploitation/"><?xxe-sn 2fchdmt7vgg a?>Exploitation</link>:
we are working with the external resource <code><?xxe-sn 2fchdmt7vgg b?>webpage</code>
and want to take into account an exact order of resource exploiting
operations. Then, we write code like this:</para>
<programlisting><?xxe-sn 2fchdmt7vgg c?>send("Header"):: Content; eov_checkpoint(webpage, header).</programlisting>
<para><?xxe-sn 2fchdmt7vgg d?>We mark the operations we are interesting in
as <emphasis><?xxe-sn 2fchdmt7vgg e?>checkpoints</emphasis>(here
<code><?xxe-sn 2fds09lgw74 1?>header</code> is the name of a checkpoint
and <code><?xxe-sn 2fds09lgw74 3?>webpage</code> is the resource the
checkpoint refers to) and want to know are checkpoints executed in the
expected(as defined above) order.</para>
<para><?xxe-sn 2fchdmt7vgg f?>If it so happens that these blocks are
constructed in the correct order in our program we <emphasis><?xxe-sn 2fchdmt7vgg 6?>may</emphasis>
send them immediately. Otherwise, we must cache already constructed
content till a whole page is generated to ensure correctness. In other
words, clearly, there is an opportunity for optimizations for caching has
not only memory overhead but delays response latency(time before the first
block is sent) as well. We write two implementations <code><?xxe-sn 2fchdmt7vgg 7?>immediate_output</code>
and <code><?xxe-sn 2fchdmt7vgg 8?>cached_output</code> each for the
corresponding case:</para>
<programlisting xml:id="ExampleEov_1_Specializations"><?xxe-sn 2fchdmt7vgg 9?>name="tests/exploitation.cpp: Exploitation.Doc_ExampleEov_1", lines=15
//type to store either sending error code or cached content
Content = type variant {
errcode:: int,
message:: string
}.
//Send immediately:
guard:: immediate_output
{
send = function(content:: string):: Content
{
errcode(printf("%s", content))
}
}
//Cache content to send it later:
guard:: cached_output
{
send = function(content:: string):: Content
{
message(content)
}
}</programlisting>
<para><?xxe-sn 2fchdmt7vgg g?>These implementations should be registered
for the compiler to know which one to use:</para>
<programlisting xml:id="ExampleEov_1_Registration"><?xxe-sn 2fchdmt7vgg h?>name="tests/exploitation.cpp: Exploitation.Doc_ExampleEov_1", lines=15
eov_analysis(
success, immediate_output;
fail, cached_output
).</programlisting>
<para><?xxe-sn 2fchdmt7vgg i?>Predicate <code><?xxe-sn 2fchdmt7vgg j?>eov_analysis</code>
compares actual checkpoints execution order with the expected one and
chooses either of two implementations depending on the result. This way,
it is guarantied that immediate sending is chosen only if it is safe to do
so to avoid unnecessary caching.</para>
<para><?xxe-sn 2fchdmt7vgg k?>Thus we can safely change and adapt our
program knowing that clients always receive web page's content in the
correct order by automatically employing the most efficient content
delivery strategy depending on particular circumstances.</para>
</section>
<section>
<?xxe-sn 2fs1xxghz93 -wunr7fl0rw8u?>
<title><?xxe-sn 2fs1xxghz93 -wunr7fl0rw8t?>Differences from other
languages</title>
<para><?xxe-sn 2fs1xxghz93 -wunr7fl0rw8s?>it is convenient to talk about
<emphasis><?xxe-sn 2fs1xxghz93 -wunr7fl0rw88?>intentions</emphasis> in
order to outline a vast landscape of programming languages and point out
the place of Xreate on it, i.e. to compare languages on a basis do they
allow to express a developer's intentions along with raw code that can be
used on many occasions, e.g. to validate code's correctness. Traditionally
type system is used to declare intentions. At closer look, types in
(imperative) statically typed languages contain information as
follows:</para>
<itemizedlist>
<?xxe-sn 2fs1xxghz93 -wunr7fl0rw8q?>
<listitem>
<?xxe-sn 2fs1xxghz93 -wunr7fl0rw8p?>
<para><?xxe-sn 2fs1xxghz93 -wunr7fl0rw8o?>Intentions, such as "that
variable is a string". </para>
</listitem>
<listitem>
<?xxe-sn 2fs1xxghz93 -wunr7fl0rw8n?>
<para><?xxe-sn 2fs1xxghz93 -wunr7fl0rw8m?>Usage patterns. A new code
should play nicely with the rest of a program, e.g. if a program works
with Unicode, a new string variable should be also of Unicode
type.</para>
</listitem>
<listitem>
<?xxe-sn 2fs1xxghz93 -wunr7fl0rw8l?>
<para><?xxe-sn 2fs1xxghz93 -wunr7fl0rw8k?>Platform constraints, e.g.
if a platform supports wide strings natively, a new string variable
should also be a wide string.</para>
</listitem>
</itemizedlist>
<para><?xxe-sn 2fs1xxghz93 -wunr7fl0rw8j?>In this regard, in general,
statically typed languages are <emphasis><?xxe-sn 2fs1xxghz93 -wunr7fl0rw8i?>overconstrained</emphasis>,
they require developers to provide more information then they intend to.
This generally hinders code reuse and adaptation; to work on a new
platform, code requires porting: a process of re-expressing underlying
intentions once again with the new platform's constraints. </para>
<para><?xxe-sn 2fs1xxghz93 -wunr7fl0rw8h?>On the other side, dynamically
typed languages in this regard are <emphasis><?xxe-sn 2fs1xxghz93 -wunr7fl0rw8g?>underconstrained</emphasis>,
since they do not allow to express all desirable intentions. This leads to
a disastrous inefficiency and code fragility because any errors can be
caught only at runtime. </para>
<para><?xxe-sn 2fs1xxghz93 -wunr7fl0rw8f?>OOP languages are hugely
successful among other reasons because they provide <emphasis><?xxe-sn 2fs1xxghz93 -wunr7fl0rw8e?>classes</emphasis>
to more finely express intentions, e.g. <code><?xxe-sn 2fs1xxghz93 -wunr7fl0rw8d?>String</code>,
<code><?xxe-sn 2fs1xxghz93 -wunr7fl0rw8c?>UnicodeString</code>,
<code><?xxe-sn 2fs1xxghz93 -wunr7fl0rw8b?>Utf8String</code> with exact
behaviour being hidden in implementation details.</para>
<para><?xxe-sn 2fs1xxghz93 -wunr7fl0rw8a?>Xreate in its turn offers
annotations for developers to express intentions, e.g. <code><?xxe-sn 2fs1xxghz93 -wunr7fl0rw87?>string;i_dont_need(cow)</code>
(copy-on-write implementation). Annotations alone is not enough to fully
determine necessary types thus the compiler finishes them by looking at
usage patterns along with platform properties in order to infer most
efficient implementations.</para>
<para><?xxe-sn 2fs1xxghz93 -wunr7fl0rw86?>Also there is an area beyond
type systems capabilities, since types are designed to express intentions
only about data flow. However as shown in the previous example it is also
useful to express intentions about program structure properties, such as
operations order. </para>
</section>
</chapter>

Event Timeline

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