diff --git a/.github/workflows/latexmk.yml b/.github/workflows/latexmk.yml
index 5592eed7a6..44660dc755 100644
--- a/.github/workflows/latexmk.yml
+++ b/.github/workflows/latexmk.yml
@@ -11,7 +11,7 @@ concurrency:
cancel-in-progress: true
jobs:
latexmk:
- runs-on: ubuntu-latest
+ runs-on: ubuntu-22.04
steps:
- uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4
- uses: yegor256/latexmk-action@0.10.9
diff --git a/.github/workflows/shellcheck.yml b/.github/workflows/shellcheck.yml
index ad721aa9d9..eec93d4fd0 100644
--- a/.github/workflows/shellcheck.yml
+++ b/.github/workflows/shellcheck.yml
@@ -15,8 +15,7 @@ concurrency:
jobs:
shellcheck:
name: Shellcheck
- runs-on: ubuntu-latest
+ runs-on: ubuntu-22.04
steps:
- uses: actions/checkout@v4
- - name: Run ShellCheck
- uses: ludeeus/action-shellcheck@master
+ - uses: ludeeus/action-shellcheck@master
diff --git a/paper/.gitignore b/paper/.gitignore
index 3c7bc6933a..30cc924adc 100644
--- a/paper/.gitignore
+++ b/paper/.gitignore
@@ -13,4 +13,7 @@ _minted-*
*.out
*.synctex.gz
*.zip
-package/
\ No newline at end of file
+package/
+iexec.ret
+*-SAVE-ERROR
+_eolang/
\ No newline at end of file
diff --git a/paper/DEPENDS.txt b/paper/DEPENDS.txt
index 7c62f3f2d9..aecf3fc238 100644
--- a/paper/DEPENDS.txt
+++ b/paper/DEPENDS.txt
@@ -3,7 +3,6 @@ hard algorithmicx
hard algpseudocodex
hard anyfontsize
hard babel-russian
-hard biblatex
hard biber
hard cancel
hard catchfile
@@ -48,3 +47,7 @@ hard trimspaces
hard upquote
hard wrapfig
hard xstring
+hard cleveref
+hard adjustbox
+hard bibcop
+hard silence
\ No newline at end of file
diff --git a/paper/Makefile b/paper/Makefile
index e3483afd98..800a4d8d06 100644
--- a/paper/Makefile
+++ b/paper/Makefile
@@ -20,8 +20,10 @@
# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
# SOFTWARE.
-.SHELLFLAGS = -e -x -c
+.SHELLFLAGS=-e -x -c
.ONESHELL:
+.PHONY: clean
+SHELL=bash
TLROOT=$$(kpsewhich -var-value TEXMFDIST)
PACKAGES=ffcode to-be-determined href-ul minted
@@ -43,7 +45,7 @@ zip: *.tex sections/*.tex
${gsed} -i "s|0\.0\.0|$${version}|g" eolang-paper.tex
${gsed} -i "s|REPOSITORY|$(REPO)|g" eolang-paper.tex
pdflatex -shell-escape -halt-on-error eolang-paper.tex > /dev/null
- biber eolang-paper
+ bibtex eolang-paper
pdflatex -halt-on-error eolang-paper.tex > /dev/null
pdflatex -halt-on-error eolang-paper.tex > /dev/null
rm -rf *.aux *.bcf *.blg *.fdb_latexmk *.fls *.log *.run.xml *.out *.exc
diff --git a/paper/aspell.en.pws b/paper/aspell.en.pws
index d8e09d0122..cb34b101d3 100644
--- a/paper/aspell.en.pws
+++ b/paper/aspell.en.pws
@@ -56,4 +56,5 @@ GOTO
unary
decoratee
cmtt
-attr
\ No newline at end of file
+attr
+acmart
\ No newline at end of file
diff --git a/paper/eolang-paper.tex b/paper/eolang-paper.tex
index 6d45a09528..f614fef14e 100644
--- a/paper/eolang-paper.tex
+++ b/paper/eolang-paper.tex
@@ -20,19 +20,11 @@
% OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
% SOFTWARE.
-\documentclass[sigplan,nonacm,natbib=false]{acmart}
+\documentclass[sigplan,nonacm]{acmart}
\settopmatter{printfolios=false,printccs=false,printacmref=false}
\usepackage[utf8]{inputenc}
-\usepackage[maxnames=1,minnames=1,maxbibnames=100,natbib=true,citestyle=authoryear,bibstyle=authoryear,doi=false,url=false,isbn=false,isbn=false,backend=biber]{biblatex}
-\addbibresource{main.bib}
-
-\ifnum\pdfshellescape=1
- \usepackage[finalizecache]{minted}
-\else
- \usepackage[frozencache]{minted}
-\fi
-
\usepackage[T2A,T1]{fontenc}
+\usepackage{natbib} % for \citep and \citet
\usepackage{stmaryrd} % for arrows, like \mapstochar
\let\Bbbk\relax\usepackage{amssymb} % for special symbols
\usepackage{amsmath}
@@ -41,10 +33,13 @@
\usepackage{csquotes}
\usepackage[novert]{ffcode} % for fixed-fonts
\usepackage{phigure} % local, in this directory
+\usepackage[capitalize]{cleveref} % for \cref
\usepackage{CJKutf8} % for chinese font
\usepackage{paralist} % for inlined lists
\usepackage{cancel} % to enable \cancel command
\usepackage{anyfontsize} % To get rid of font not found warnings
+\usepackage{eolang} % for EO sources and formulas
+\usepackage{bibcop} % for checking quality of the .bib file
\usepackage{tabularx} % for special tables
\usepackage{to-be-determined} % for \tbd command
\usepackage{href-ul} % for nicely underscored links
@@ -55,6 +50,9 @@
\usepackage{pgffor} % to enable \foreach
\usepackage{mathtools} % for matrix* environment
+\usepackage{silence}
+ \WarningFilter{acmart}{\vspace should only be used to provide space above/below}
+
\tolerance=1500
\raggedbottom
\setlength\headheight{21pt}
@@ -62,9 +60,6 @@
\newcommand\nospell[1]{#1}
\newcommand\br{\\[-4pt]}
\newcommand\figcap[1]{\caption{#1}\Description{#1}}
-\newcommand\phic{$\varphi$-calculus}
-\newcommand\eo{{\sffamily EO}}
-\newcommand\XMIR{{\sffamily XMIR}}
\newcommand\lref[1]{the line no.~\ref{ln:#1}}
\newcommand\lrefs[2]{the lines~\ref{ln:#1}--\ref{ln:#2}}
@@ -88,7 +83,7 @@
\setlength{\footskip}{13.0pt}
\acmBooktitle{untitled}
-\title{EOLANG and \texorpdfstring{$\varphi$}{phi}-calculus}
+\title{EOLANG and \texorpdfstring{\(\varphi\)}{phi}-calculus}
\subtitle{%
Ver:
\texorpdfstring{
@@ -117,12 +112,12 @@
the rendered version is \href{https://github.com/REPOSITORY/releases/tag/0.0.0}{\ff{0.0.0}}.}.
However, despite
its industrial and academic popularity, OOP is still missing
-a formal apparatus similar to $\lambda$-calculus, which functional
+a formal apparatus similar to \(\lambda\)-calculus, which functional
programming is based on. There were a number of attempts to formalize
OOP, but none of them managed to cover all the features available in
modern OO programming languages, such as C++ or Java.
We have made yet another attempt and created \phic{}. We also
-created EOLANG (also called \eo{}), an experimental
+created EOLANG (also called \eolang{}), an experimental
programming language based on \phic{}.
\end{abstract}
@@ -134,12 +129,12 @@ \section{Introduction}
\input{sections/overview}
The rest of the paper is dedicated to the discussion of the
-syntax of the language we created based on the calculus,
+syntax of the language that we created based on the calculus,
the calculus itself, its semantics, and pragmatics.
In order to make it easier to understand, we start
the discussion with the syntax of the language, while the calculus
is derived from it. Then, we discuss the
-key features of \eo{} and the differences between it and other
+key features of \eolang{} and the differences between it and other
programming languages. We also discuss how the absence of traditional
OOP features, such as mutability or inheritance, affect the complexity of code.
At the end of the paper we overview the work done by others in the area of
@@ -153,17 +148,17 @@ \section{Calculus}
\label{sec:calculus}
\input{sections/calculus}
-\section{Semantics}
-\label{sec:semantics}
-\input{sections/semantics}
+% \section{Semantics}
+% \label{sec:semantics}
+% \input{sections/semantics}
-\section{Pragmatics}
-\label{sec:pragmatics}
-\input{sections/pragmatics}
+% \section{Pragmatics}
+% \label{sec:pragmatics}
+% \input{sections/pragmatics}
-\section{XMIR}
-\label{sec:xmir}
-\input{sections/xmir}
+% \section{XMIR}
+% \label{sec:xmir}
+% \input{sections/xmir}
\section{Key Features}
\label{sec:features}
@@ -184,7 +179,9 @@ \section{Related Work}
\section{Acknowledgments}
\input{sections/acks}
-\printbibliography
+{\raggedright
+\bibliographystyle{ACM-Reference-Format}
+\bibliography{main}}
\clearpage
diff --git a/paper/sections/acks.tex b/paper/sections/acks.tex
index 3376c9d136..d678a088aa 100644
--- a/paper/sections/acks.tex
+++ b/paper/sections/acks.tex
@@ -8,7 +8,7 @@
\nospell{Ali-Sultan Ki-giz\-ba\-ev},
\nospell{Nikolai Ku\-da\-sov},
\nospell{Alexander Legalov},
- \nospell{Tymur $\lambda$ysenko},
+ \nospell{Tymur \(\lambda\)ysenko},
\nospell{Alexandr Naumchev},
\nospell{Alonso A. Ortega},
\nospell{John Page},
@@ -20,9 +20,11 @@
\nospell{Sergei Skliar},
\nospell{Stian Soiland-Reyes},
\nospell{Viacheslav Tradunskyi},
+ \nospell{Maxim Trunnikov},
\nospell{Ilya Trub},
\nospell{César Soto Valero},
+ \nospell{David West},
and
- \nospell{David West}
-for their contribution to the development of \eo{} and \phic{}.
+ \nospell{Vladimir Zakharov}
+for their contribution to the development of \eolang{} and \phic{}.
diff --git a/paper/sections/calculus.tex b/paper/sections/calculus.tex
index 0e7d0f8c9e..17c1a26bce 100644
--- a/paper/sections/calculus.tex
+++ b/paper/sections/calculus.tex
@@ -1,16 +1,16 @@
The proposed \phic{} is based on set theory~\citep{jech2013set} and lambda calculus,
-representing objects as sets of pairs and their internals as $\lambda$-terms.
+representing objects as sets of pairs and their internals as \(\lambda\)-terms.
The rest of the section contains formal definitions of
-data, objects, attributes, abstraction, application, decoration, and dataization.
+data, objects, attributes, formation, application, decoration, and dataization.
\subsection{Objects and Data}
\begin{definition}\label{def:object}
-An \textbf{object} is a set of ordered pairs $(a_i, v_i)$ such that
-$a_i$ is an identifier, all $a_i$ are different, and $v_i$ is an object.
+An \textbf{object} is a set of ordered pairs \((a_i, v_i)\) such that
+\(a_i\) is an identifier, all \(a_i\) are different, and \(v_i\) is an object.
\end{definition}
-An identifier is either $\varphi$, $\rho$, $\nu$, or, by convention, a text without
+An identifier is either \(\varphi\), \(\rho\), \(\sigma\), \(\nu\), or, by convention, a text without
spaces starting with a small-case English letter in typewriter font.
The object at \lref{book} may be represented as
@@ -21,8 +21,8 @@ \subsection{Objects and Data}
\end{matrix*}\right\},
\end{split}
\end{equation}
-where \ff{isbn} is an identifier and $\varnothing$ is an empty
-set, which is a proper object, according to the Def.~\ref{def:object}.
+where \ff{isbn} is an identifier and \(\varnothing\) is an empty
+set, which is a proper object, according to~\cref{def:object}.
\begin{definition}\label{def:data}
An object may have properties of \textbf{data},
@@ -52,54 +52,53 @@ \subsection{Objects and Data}
\subsection{Attributes}
\begin{definition}\label{def:attribute}
-In an object $x$, $a$ is a free \textbf{attribute}
-with the \textbf{name} $a$
-iff $(a, \varnothing) \in x$; it is a bound attribute
-with the \textbf{value} $v$
-iff $\exists (a, v)\in x$ and $v\not=\varnothing$;
+In an object \(x\), \(a\) is a void \textbf{attribute}
+with the \textbf{name} \(a\)
+iff \((a, \varnothing) \in x\); it is an attached attribute
+with the \textbf{value} \(v\)
+iff \(\exists (a, v)\in x\) and \(v\not=\varnothing\);
\end{definition}
-In Eq.~\ref{eq:book2}, identifiers \ff{isbn}, \ff{title}, and \ff{price}
+In \cref{eq:book2}, identifiers \ff{isbn}, \ff{title}, and \ff{price}
are the attributes of the object \ff{book2}.
-The attribute \ff{isbn} is free, while the other two are bound.
+The attribute \ff{isbn} is void, while the other two are attached.
\begin{definition}\label{def:dot}
-If $x$ is an object and $\exists (a, v) \in x$, then $v$ may be referenced as $x.a$;
+If \(x\) is an object and \(\exists (a, v) \in x\), then \(v\) may be referenced as \(x.a\);
this referencing mechanism is called \textbf{dot notation}.
\end{definition}
-Both free and bound attributes of an object are accessible using
+Both void and attached attributes of an object are accessible using
the dot notation. There is no such thing as
visibility restriction in \phic{}:
all attributes are visible to all objects outside of the one they belong to.
It is possible to chain attribute references using dot notation, for example
-$\ff{book2}.\ff{price}.\ff{neg}$ is a valid expression, which means
+\(\ff{book2}.\ff{price}.\ff{neg}\) is a valid expression, which means
``taking the attribute \ff{price} from the object \ff{book2} and then
taking the attribute \ff{neg} from it.''
\begin{definition}\label{def:scope}
-If $x(a_i, v_i)$ is an object, then $\hat{x}$, a set consisting of all $a_i$,
-is its \textbf{scope} and the cardinality of $|\hat{x}|$ is
-the \textbf{arity} of $x$.
+If \(x(a_i, v_i)\) is an object, then \(\hat{x}\), a set consisting of all \(a_i\),
+is its \textbf{scope} and the cardinality of \(|\hat{x}|\) is
+the \textbf{arity} of \(x\).
\end{definition}
-For example, the scope of the object at Eq.~\ref{eq:book2} consists of three identifiers:
+For example, the scope of the object at~\cref{eq:book2} consists of three identifiers:
\ff{isbn}, \ff{title}, and \ff{price}.
-\subsection{Abstraction}
+\subsection{Formation}
\begin{definition}\label{def:abstraction}
-An object $x$ is \textbf{abstract} iff at least one of its attributes is free,
-i.e. $\exists (a, \varnothing)\in x$;
-the process of creating such an object is called \textbf{abstraction}.
+An object \(x\) is \textbf{abstract} iff at least one of its attributes is void,
+i.e. \(\exists (a, \varnothing)\in x\).
\end{definition}
-An alternative ``arrow notation'' may be used to denote an object $x$ in a more
-compact way, where free attributes stay in the parentheses on the left side of the
-mapping symbol $\mapsto$ and pairs,
-which represent bound attributes, stay on the right side, in double-square brackets.
-Eq.~\ref{eq:book2} may be written as
+An alternative ``arrow notation'' may be used to denote an object \(x\) in a more
+compact way, where void attributes stay in the parentheses on the left side of the
+mapping symbol \(\mapsto\) and pairs,
+which represent attached attributes, stay on the right side, in double-square brackets.
+\Cref{eq:book2} may be written as
\begin{equation}\label{eq:book2-compact}
\begin{split}
& \ff{book2}(\ff{isbn}) \mapsto \llbracket \br
@@ -112,30 +111,30 @@ \subsection{Abstraction}
\subsection{Application}
\begin{definition}\label{def:application}
-If $x$ is an abstract object and $y$ is an object
- where $\hat{y}\subseteq\hat{x}$,
- then an \textbf{application} of $y$ to $x$ is
- a \textbf{copy} of $x$, a new object that consists of pairs $(a\in\hat{x},v)$ such that
- $v=y.a$ if $x.a=\varnothing$ and $v=x.a$ otherwise.
+If \(x\) is an abstract object and \(y\) is an object
+ where \(\hat{y}\subseteq\hat{x}\),
+ then an \textbf{application} of \(y\) to \(x\) is
+ a \textbf{copy} of \(x\), a new object that consists of pairs \((a\in\hat{x},v)\) such that
+ \(v=y.a\) if \(x.a=\varnothing\) and \(v=x.a\) otherwise.
\end{definition}
-Application makes some free attributes of $x$ bound---by binding objects to them.
+Application makes some void attributes of \(x\) attached---by binding objects to them.
The produced object has exactly the same set of attributes, but some of them,
-which were free before, become bound.
+which were void before, become attached.
-It is not expected that all free attributes turn into bound ones during application.
-Some of them may remain free, which will lead
+It is not expected that all void attributes turn into attached ones during application.
+Some of them may remain void, which will lead
to creating a new abstract object. To the contrary,
-if all free attributes are substituted with \emph{arguments} during copying,
+if all void attributes are substituted with \emph{arguments} during copying,
a newly created object will be \emph{closed}.
-Once set, bound attributes may not be reset.
+Once set, attached attributes may not be reset.
This may be interpreted as \emph{immutability} property of objects.
Arrow notation may also be used to denote object copying,
-where the names of the attributes, which remain free, stay in the brackets
-on the left side of the mapping symbol $\mapsto$,
-while objects $P$ provided as arguments stay on the right side,
+where the names of the attributes, which remain void, stay in the brackets
+on the left side of the mapping symbol \(\mapsto\),
+while objects \(P\) provided as arguments stay on the right side,
in the brackets. For example, the object at \lref{point-copy} may be written as
\begin{equation}\label{eq:point}
\begin{split}
@@ -152,8 +151,8 @@ \subsection{Application}
\end{equation}
An application without arguments is a copy of an object. For example,
-in these expressions the attribute \ff{p1} is bound to the same object
-as the attribute \ff{p}, while the attribute \ff{p2} is bound to a new
+in these expressions the attribute \ff{p1} is attached to the same object
+as the attribute \ff{p}, while the attribute \ff{p2} is attached to a new
object, a copy of \ff{p}:
\begin{equation*}
\begin{split}
@@ -163,16 +162,18 @@ \subsection{Application}
\end{split}
\end{equation*}
+\subsection{Formation}
+
\begin{definition}\label{def:formation}
The process of creating an object that is not a copy of another object
is called \textbf{formation}.
\end{definition}
Syntactically, object formation is denoted by double square brackets,
-as in Eq.~\ref{eq:book2-compact}, to the contrary of object application,
-which is denoted by round brackets, as in Eq.~\ref{eq:point}.
+as in \cref{eq:book2-compact}, to the contrary of object application,
+which is denoted by round brackets, as in \cref{eq:point}.
Object abstraction is a special case of object formation.
-The following expression is a formation of the object $x$:
+The following expression is a formation of the object \(x\):
\begin{equation*}
x \mapsto [[ y -> t ]].
\end{equation*}
@@ -180,8 +181,8 @@ \subsection{Application}
\subsection{Parent and Home}
\begin{definition}\label{def:parent}
-If $x$ is an object, then $x.\rho$ is its \textbf{parent},
-which is the object that created $x$.
+If \(x\) is an object, then \(x.\rho\) is its \textbf{parent},
+which is the object that created \(x\).
\end{definition}
An object may be created either by
@@ -205,8 +206,8 @@ \subsection{Parent and Home}
\end{equation}
\begin{definition}\label{def:home}
-If $x$ is an object, then $x.\sigma$ is its \textbf{home} object, which
-is the $\rho$ of the abstract object $x$ is a copy of.
+If \(x\) is an object, then \(x.\sigma\) is its \textbf{home} object, which
+is the \(\rho\) of the abstract object \(x\) is a copy of.
\end{definition}
For example:
@@ -223,12 +224,12 @@ \subsection{Parent and Home}
\subsection{Decoration}\label{sec:decoration}
\begin{definition}\label{def:decorator}
-If $x$ and $y$ are objects and $x.\varphi = y$, then
- $\forall a (x.a = y.a)$ if $a \not\in \hat{x}$;
- this means that $x$ is \textbf{decorating} $y$.
+If \(x\) and \(y\) are objects and \(x.\varphi = y\), then
+ \(\forall a (x.a = y.a)\) if \(a \not\in \hat{x}\);
+ this means that \(x\) is \textbf{decorating} \(y\).
\end{definition}
-Here, $\varphi$ is a special identifier denoting the object,
+Here, \(\varphi\) is a special identifier denoting the object,
known as a \emph{decoratee}, being decorated
within the scope of the decorator.
@@ -265,8 +266,8 @@ \subsection{Decoration}\label{sec:decoration}
\end{equation}
Because of decoration, the expression
-$\rho.\varphi.\ff{distance}$ in Eq.~\ref{eq:c-empty} is semantically equivalent to a shorter expression
-$\rho.\ff{distance}$ in Eq.~\ref{eq:c-fin}.
+\(\rho.\varphi.\ff{distance}\) in \cref{eq:c-empty} is semantically equivalent to a shorter expression
+\(\rho.\ff{distance}\) in \cref{eq:c-fin}.
The following expression makes a new object \ff{is}, which represents
a sequence of object applications ending with a copy of \ff{lte}:
@@ -296,104 +297,38 @@ \subsection{Decoration}\label{sec:decoration}
\subsection{Atoms}
\begin{definition}\label{def:atom}
-If $\lambda s.M$ is a function of one argument $s$ returning an object,
-then it is an abstract object called an \textbf{atom}, $M$ is its $\lambda$-term,
-and $s$ is its free attribute.
+If \(\lambda s.M\) is a function of one argument \(s\) returning an object,
+then it is an abstract object called an \textbf{atom}, \(M\) is its \(\lambda\)-term,
+and \(s\) is its void attribute.
\end{definition}
-For example, the atom at \lref{sum-def} would be represented as
-\begin{equation}
-\begin{split}
-& \ff{sum}(\ff{x}) \mapsto \lambda s . \sum\limits_{i=0}^{s[0].\ff{x}.\ff{size} - 1} s[0].\ff{x}.\ff{get}(i),
-\end{split}
-\end{equation}
-where the function calculates an arithmetic sum of all items
-in the tuple \ff{x} and returns the result as a data. The argument of
-the function is a vector $s$ where the first element is the object under
-consideration, the second element is its parent object, the third element
-is the parent of the parent, and so on. Thus, $s[0]$ is the object
-\ff{sum} itself, while $s[0].\ff{x}$ is its inner object \ff{x},
-and $s[0].\ff{x}.\ff{get}(0)$ is the first element of it, if it is a tuple.
-It is expected that the tuple has an attribute \ff{size} representing
-the total number of elements in the tuple.
-
-Atoms may have their $\lambda$-terms defined outside of \phic{} formal scope.
+Atoms may have their \(\lambda\)-terms defined outside of \phic{} formal scope.
For example, the object at \lref{stdout} would be denoted as
\begin{equation}\label{def:stdout}
\ff{stdout}(\ff{text}) \mapsto \lambda s.M_\texttt{stdout},
\end{equation}
-where $M_\texttt{stdout}$ is a $\lambda$-term defined externally.
+where \(M_\texttt{stdout}\) is a \(\lambda\)-term defined externally.
-In atoms, $\lambda$-terms are bound to $\lambda$ attribute.
-Thus, a more formal form of the Eq.~\ref{def:stdout} is:
+In atoms, \(\lambda\)-terms are attached to \(\lambda\) attribute.
+Thus, a more formal form of the \cref{def:stdout} is:
\begin{equation*}
\ff{stdout} \mapsto \llbracket \ff{text} \mapsto \varnothing, \lambda \mapsto M_\text{stdout} \rrbracket.
\end{equation*}
-\subsection{Locators}
-
-\begin{definition}\label{def:locator}
-Object \textbf{locator} is a unique dot-separated not-empty
-collection of identifiers prepended by either $\xi$, $\rho$, $\sigma$, or $\Phi$.
-\end{definition}
-
-Locators are used to avoid ambiguity when referencing objects.
-For example, Eq.~\ref{eq:c-fin} may be refined as
-\begin{equation}
-\begin{split}
-& \ff{c} \mapsto \llbracket \br
-& \quad \ff{center} \mapsto \Phi.\ff{point}(\Phi.\ff{-3}, \Phi.\ff{9}), \br
-& \quad \ff{radius} \mapsto \Phi.\ff{40}, \br
-& \quad \varphi \mapsto \xi.\ff{center}, \br
-& \quad \ff{is-inside}(\ff{p}) \mapsto \llbracket \br
-& \quad \quad \varphi \mapsto \rho.\ff{distance}(\xi.\ff{p}).\ff{lte}( \br
-& \quad \quad \quad \rho.\ff{radius} \br
-& \quad \quad ) \br
-& \quad \rrbracket \br
-& \rrbracket,
-\end{split}
-\end{equation}
-where $\xi$ denotes the current abstract object
-and $\Phi$ refers to the anonymous closed ``root'' object.
-Defining an object in a global scope
-means binding it to the object $\Phi$, unless it is an anonymous
-object, as the one at \lrefs{succ}{succ-end}.
-
-The most precise and complete formula for the object in the
-Eq.~\ref{eq:c-fin2} would also include attribute names for
-the object application:
-\begin{equation}
-\begin{split}
-& \ff{c} \mapsto \llbracket \br
-& \quad \ff{center} \mapsto \Phi.\ff{point}( \br
-& \quad \quad \ff{x} \mapsto \Phi.\ff{-3}, \br
-& \quad \quad \ff{y} \mapsto \Phi.\ff{9} \br
-& \quad ), \br
-& \quad \ff{radius} \mapsto \Phi.\ff{40}, \br
-& \quad \varphi \mapsto \xi.\ff{center}, \br
-& \quad \ff{is-inside}(\ff{p}) \mapsto \llbracket \br
-& \quad \quad \varphi \mapsto \xi.\rho.\ff{distance}(\ff{to} \mapsto \xi.\ff{p}).\ff{lte}( \br
-& \quad \quad \quad \ff{other} \mapsto \xi.\rho.\ff{radius} \br
-& \quad \quad ) \br
-& \quad \rrbracket \br
-& \rrbracket.
-\end{split}
-\end{equation}
-
\subsection{Constant}
\newcommand\cmapsto{\mapstochar\relbar\mathrel{\mkern-8mu}\mapsto}
\begin{definition}\label{def:identity}
-If $x \mapsto \llbracket y \cmapsto z \rrbracket$ is an object
-then $y$ is a \emph{constant} attribute, meaning that
-the result of dataization of $x.y$ always equals to itself.
+If \(x \mapsto \llbracket y \cmapsto z \rrbracket\) is an object
+then \(y\) is a \emph{constant} attribute, meaning that
+the result of dataization of \(x.y\) always equals to itself.
\end{definition}
\subsection{Identity}
\begin{definition}\label{def:constant}
-If $x$ is an object then $x.\nu$ is a positive integer data object
-with a unique identity of $x$ in the entire runtime scope.
+If \(x\) is an object then \(x.\nu\) is a positive integer data object
+with a unique identity of \(x\) in the entire runtime scope.
\end{definition}
For example, without any other objects in scope it is safe
diff --git a/paper/sections/complexity.tex b/paper/sections/complexity.tex
index 6cba974eab..9bc4fd2108 100644
--- a/paper/sections/complexity.tex
+++ b/paper/sections/complexity.tex
@@ -16,7 +16,7 @@
, %
\fi%
P\ref{ptn:\r}%
- } $\to$
+ } \(\to\)
}
\begin{itemize}
@@ -44,10 +44,10 @@
of the design patterns listed above are possible and may be
utilized by programmers in their code, letting them write
code with higher complexity. To the contrary, they
-are not permitted in \eo{} by design:
+are not permitted in \eolang{} by design:
\begin{itemize}
-\solution{return-null,accept-null} There are no NULLs in~\eo{}
+\solution{return-null,accept-null} There are no NULLs in~\eolang{}
\solution{utility,factory,singleton} There are no static methods
\solution{inheritance} There is no inheritance
\solution{mutable,setters} There are no mutable objects
@@ -60,7 +60,7 @@
\solution{formatting} The syntax explicitly defines style
\end{itemize}
-Thus, since in \eo{} all patterns listed above
-are not permitted by the language design, \eo{} programs
+Thus, since in \eolang{} all patterns listed above
+are not permitted by the language design, \eolang{} programs
will have lower complexity while being written by the same group
of programmers.
diff --git a/paper/sections/features.tex b/paper/sections/features.tex
index df86cfcb66..458426a14d 100644
--- a/paper/sections/features.tex
+++ b/paper/sections/features.tex
@@ -5,36 +5,36 @@
#2%
}.\;}}
-There are a few features that distinguish \eo{} and \phic{}
+There are a few features that distinguish \eolang{} and \phic{}
from other existing OO languages and object theories, while some of
them are similar to what other languages have to offer. The Section is not
intended to present the features formally, which was done earlier in
-Sections~\ref{sec:calculus} and~\ref{sec:syntax}, but to compare \eo{} with other
+\cref{sec:calculus,sec:syntax}, but to compare \eolang{} with other
programming languages and informally identify similarities.
\feature{no-classes}{No Classes}
%
-\eo{} is similar to other delegation-based languages like Self~\citep{ungar1987self},
+\eolang{} is similar to other delegation-based languages like Self~\citep{ungar1987self},
where objects are not created by a class as in class-based languages like C++ or Java,
but from another object, inheriting properties from the original.
However, while in such languages, according to~\citet{fisher1995delegation},
``an object may be created,
and then have new methods added or existing methods redefined,''
-in \eo{} such object alteration is not allowed.
+in \eolang{} such object alteration is not allowed.
\feature{no-types}{No Types}
%
-Even though there are no types in \eo{}, compatibility
+Even though there are no types in \eolang{}, compatibility
between objects may be inferred in compile-time and validated strictly, which other
\nospell{typeless} languages such as Python,
Julia~\citep{bezanson2012julia},
Lua~\citep{ierusalimschy2016lua},
or Erlang~\citep{erlang2020manual} can't guarantee.
-Also, there is no type casting or reflection on types in \eo{}.
+Also, there is no type casting or reflection on types in \eolang{}.
\feature{no-inheritance}{No Inheritance}
%
-It is impossible to inherit attributes from another object in \eo{}.
+It is impossible to inherit attributes from another object in \eolang{}.
The only two possible ways to re-use functionality are either via object
composition or decorators.
There are OO languages without implementation inheritance, for example Go~\citep{donovankernighan2015go},
@@ -44,52 +44,52 @@
\feature{no-methods}{No Methods}
%
-An object in \eo{} is a composition of other objects and atoms:
+An object in \eolang{} is a composition of other objects and atoms:
there are no methods or functions similar to Java or C++ ones.
Execution control is given to a program when atoms' attributes are referred to.
-Atoms are implemented by \eo{} runtime similar to Java native objects.
+Atoms are implemented by \eolang{} runtime similar to Java native objects.
To our knowledge, there are no other OO languages without methods.
\feature{no-ctors}{No Constructors}
%
-Unlike Java or C++, \eo{} doesn't allow programmers to alter
+Unlike Java or C++, \eolang{} doesn't allow programmers to alter
the process of object construction or suggest alternative
paths of object instantiation via additional constructions.
-Instead, all arguments are assigned to attributes ``as is'' and can't be modified.
+Instead, all arguments are attached to attributes ``as is'' and can't be modified.
\feature{no-static}{No Static Entities}
%
Unlike Java and C\#,
-\eo{} objects may consist only of other objects, represented
+\eolang{} objects may consist only of other objects, represented
by attributes, while class methods, also known as static methods, as well as
-static literals, and static blocks---don't exist in \eo{}.
+static literals, and static blocks---don't exist in \eolang{}.
Considering modern programming languages, Go has no static methods either,
but only objects and ``\nospell{structs}''~\citep{schmager2010gohotdraw}.
\feature{no-primitives}{No Primitive Data Types}
%
-There are no primitive data types in \eo{}, which
+There are no primitive data types in \eolang{}, which
exist in Java and C++, for example.
As in Ruby, Smalltalk~\citep*{goldbergrobson1983smalltalk}, Squeak, Self, and Pharo,
integers, floating point numbers, boolean
-values, and strings are objects in \eo{}:
+values, and strings are objects in \eolang{}:
``everything is an object'' is the key design principle, which,
according to~\citet[p.66]{west2004object}, is an ``obviously necessary prerequisite
to object thinking.''
\feature{no-operators}{No Operators}
%
-There are no operators like \ff{+} or \ff{/} in \eo{}. Instead,
+There are no operators like \ff{+} or \ff{/} in \eolang{}. Instead,
numeric objects have built-in atoms that represent math operations. The same
is true for all other manipulations with objects: they are provided
only by their encapsulated objects, not by external language constructs, as in
-Java or C\#. Here \eo{} is similar to Ruby, Smalltalk and Eiffel,
+Java or C\#. Here \eolang{} is similar to Ruby, Smalltalk and Eiffel,
where operators are syntax sugar, while implementation is encapsulated in
the objects.
\feature{no-null}{No NULL References}
%
-Unlike C++ and Java, there is no concept of NULL in \eo{}, which
+Unlike C++ and Java, there is no concept of NULL in \eolang{}, which
was called a ``billion dollar mistake'' by~\citet{hoare2009null} and
is one of the key threats for design consistency~\citep{eo1}.
Haskell, Rust, OCaml, Standard ML, and Swift also don't have NULL references.
@@ -97,7 +97,7 @@
\feature{no-empty}{No Empty Objects}
%
Unlike Java, C++ and all other OO languages,
-empty objects with no attributes are forbidden in \eo{} in order
+empty objects with no attributes are forbidden in \eolang{} in order
to guarantee the presence of object composition and
enable separation of concerns~\citep{dijkstra1982role}:
larger objects must always encapsulate smaller ones.
@@ -105,7 +105,7 @@
\feature{no-private}{No Private Attributes}
%
Similar to Python~\citep{lutz2013learning} and Smalltalk~\citep{hunt1997smalltalk},
-\eo{} makes all object attributes publicly visible.
+\eolang{} makes all object attributes publicly visible.
There are no protected ones, because there is no implementation
inheritance, which is considered harmful~\citep{hunt2000}.
There are no private attributes either, because information
@@ -114,15 +114,15 @@
\feature{no-global}{No Global Scope}
%
-All objects in \eo{} are assigned to some attributes. Objects constructed
-in the global scope of visibility are assigned to attributes of the
-$\Phi$ object of the highest level of abstraction.
+All objects in \eolang{} are attached to some attributes. Objects constructed
+in the global scope of visibility are attached to attributes of the
+\(\Phi\) object of the highest level of abstraction.
Newspeak and Eiffel are two programming languages that does not have global scope as well.
\feature{no-mutability}{No Mutability}
%
Similar to Erlang~\citep{armstrong2010erlang},
-there are only immutable objects in \eo{}, meaning that their attributes may
+there are only immutable objects in \eolang{}, meaning that their attributes may
not be changed after the object is constructed or copied.
Java, C\#, and C++, have modifiers like
\ff{final}, \ff{readonly}, or \ff{const} to make attributes immutable, which
@@ -130,7 +130,7 @@
always expose the same functionality, the former may represent mutable
entities, being known as read-only references~\citep{birka2004practical}.
For example, an attribute \ff{r} may have an object \ff{random.pseudo}
-assigned to it, which is a random number generator. \eo{} won't allow
+attached to it, which is a random number generator. \eolang{} won't allow
assigning another object to the attribute \ff{r}. However, every time
the attribute is dataized, its value will be different.
%
@@ -144,26 +144,26 @@
%
In most OO languages exception handling~\citep{goodenough1975exception}:
happens through an imperative error-throwing statement.
-Instead, \eo{} has a declarative mechanism for it, which
+Instead, \eolang{} has a declarative mechanism for it, which
is similar to Null Object design pattern~\citep{martin1997pattern}: returning
an abstract object causes program execution to stop once the returned
object is dealt with.
\feature{no-functions}{No Functions}
%
-There are no lambda objects or functions in \eo{}, which exist in Java~8+, for example.
-However, objects in \eo{} have ``bodies,'' which make it possible to interpret
+There are no lambda objects or functions in \eolang{}, which exist in Java~8+, for example.
+However, objects in \eolang{} have ``bodies,'' which make it possible to interpret
objects as functions.
-Strictly speaking, if objects in \eo{} would only have bodies and no other attributes,
+Strictly speaking, if objects in \eolang{} would only have bodies and no other attributes,
they would be functions. It is legit to
-say that \eo{} extends lambda calculus, but in a different way
+say that \eolang{} extends lambda calculus, but in a different way
comparing to previous attempts made by~\citet{mitchell1993lambda} and \citet{di1998lambda}:
-methods and attributes in \eo{} are not new concepts, but lower-level
+methods and attributes in \eolang{} are not new concepts, but lower-level
objects.
\feature{no-mixins}{No mixins}
%
-There are no ``traits'' or ``mixins'' in~\eo{}, which exist in Ruby and PHP to enable
+There are no ``traits'' or ``mixins'' in~\eolang{}, which exist in Ruby and PHP to enable
code reuse from other objects without inheritance and composition.
diff --git a/paper/sections/four.tex b/paper/sections/four.tex
index 82777a1f6b..e52be2e667 100644
--- a/paper/sections/four.tex
+++ b/paper/sections/four.tex
@@ -1,6 +1,6 @@
In order to answer the question, whether
the proposed object calculus is sufficient
-to express any object model, we are going to demonstrate
+to express any object model, in this Section we demonstrate
how four fundamental principles of OOP are realized by \phic{}:
encapsulation, abstraction, inheritance, and polymorphism.
@@ -17,10 +17,14 @@ \subsection{Abstraction}
`knife' used to carve our domain into discrete objects.''
In \phic{} objects are the elements the problem domain
-is decomposed into, which goes along the claim of~\citet[p.24]{west2004object}:
+is decomposed into.
+This goes along the claim of~\citet[p.24]{west2004object}:
``objects, as abstractions of entities in the real world,
represent a particularly dense and cohesive clustering of information.''
+% Mention that dynamic dispatch, as the main property of abstraction,
+% exists in EO.
+
\subsection{Inheritance}
Inheritance, according to~\citet{grady2007object}, is
@@ -155,7 +159,7 @@ \subsection{Polymorphism}
the comformance between objects is derived and ``strongly'' checked
in compile time. In the example above, it would not be possible to
compile the code that adds elements to the set \ff{emps}, if any
-of them lacks the attribute \ff{print}. Since in \eo{},
+of them lacks the attribute \ff{print}. Since in \eolang{},
there is no reflection on types or any other mechanisms
of alternative object instantiation, it is always known where
objects are constructed or copied and what is the structure of them.
@@ -195,13 +199,13 @@ \subsection{Encapsulation}
Instead, all attributes of all objects in \phic{}
are visible to any other object.
-In \eo{} the primary goal of encapsulation is achieved differently.
+In \eolang{} the primary goal of encapsulation is achieved differently.
The goal is to reduce coupling between objects:
the less they know about each other the thinner the
the connection between them, which is one of the virtues of
software design, according to~\citet{yourdon1979structured}.
-In \eo{} the tightness of coupling between objects should be controlled
+In \eolang{} the tightness of coupling between objects should be controlled
during the build, similar to how the threshold of test code coverage is
usually controlled. At compile-time the compiler collects the information
about the relationships between objects and calculates the coupling depth of each connection.
diff --git a/paper/sections/intro.tex b/paper/sections/intro.tex
index 87195375a2..47c09ee8f0 100644
--- a/paper/sections/intro.tex
+++ b/paper/sections/intro.tex
@@ -10,8 +10,8 @@
\subsection{Lack of Formal Model}
-The term OOP was coined by~\citet{kay97keynote} in 1966~\citep{kaymaster68}
-and since then was never introduced formally.
+The term OOP was coined by~\citet{kay97keynote} in 1966
+and since then was never introduced formally~\citep{kaymaster68}.
Back in 1982, \citet{rentsch1982object} predicted: ``Everyone will be in a favor
of OOP. Every manufacturer will promote his products as supporting it. Every
manager will pay lip service to it. Every programmer will practice
@@ -98,7 +98,7 @@ \subsection{High Complexity}
\subsection{Solution Proposed}
-\eo{}\footnote{\url{https://www.eolang.org}}
+\eolang{}\footnote{\url{https://www.eolang.org}}
was created in order to eliminate the problem of complexity of
OOP code, providing
\begin{inparaenum}[1)]
@@ -107,12 +107,12 @@ \subsection{Solution Proposed}
\end{inparaenum}
The proposed \phic{} represents an object model through
data and objects, while operations with them are possible
-through abstraction, application, and decoration. The calculus
+through formation, application, and decoration. The calculus
introduces a formal apparatus for manipulations with objects.
-\eo{}, the proposed programming language, fully implements
+\eolang{}, the proposed programming language, fully implements
all elements of the calculus and enables implementation of
an object model on any computational platform.
-Being an OO programming language, \eo{} enables four key principles of OOP:
+Being an OO programming language, \eolang{} enables four key principles of OOP:
abstraction, inheritance, polymorphism, and encapsulation.
diff --git a/paper/sections/overview.tex b/paper/sections/overview.tex
index 30a9ad9390..31dd3c5783 100644
--- a/paper/sections/overview.tex
+++ b/paper/sections/overview.tex
@@ -7,24 +7,24 @@
is an \emph{atom} if its implementation is provided by the runtime.
\item An object is \emph{abstract} if at least one of its attributes
-is \emph{free}---isn't \emph{bound} to any object. An object
+is \emph{void}---isn't \emph{attached} to any object. An object
is \emph{closed} otherwise.
-\emph{Abstraction} is the process of creating an abstract object.
-\emph{Application} is the process of making a \emph{copy} of an abstract
-object, specifying some or all of its free attributes with
+\emph{Formation} is the process of creating a objects.
+\emph{Application} is the process of making a \emph{copy} of existing
+object, specifying some or all of its void attributes with
objects known as \emph{arguments}. Application may lead to the
-creation of a closed object, or an abstract one, if not all free
+creation of a closed object, or an abstract one, if not all void
attributes are specified with arguments.
\item An object may \emph{decorate} another object by binding it
-to the $\varphi$ attribute of itself. A decorator has its
-own attributes and bound attributes of its decoratee.
+to the \(\varphi\) attribute of itself. A decorator has its
+own attributes and attached attributes of its decoratee.
-\item A special attribute $\Delta$ may be bound to \emph{data},
+\item A special attribute \(\Delta\) may be attached to \emph{data},
which is a computation platform dependable entity not
decomposable any further.
\emph{Dataization} is a process of retrieving data from an object,
-by taking what the $\Delta$ attribute is bound to.
+by taking what the \(\Delta\) attribute is attached to.
The dataization of an object at the highest level of composition
leads to the execution of a program.
\end{itemize}
diff --git a/paper/sections/pragmatics.tex b/paper/sections/pragmatics.tex
index 42cb038311..c8482375f1 100644
--- a/paper/sections/pragmatics.tex
+++ b/paper/sections/pragmatics.tex
@@ -1,21 +1,21 @@
-First, the source code of \eo{} is parsed by ANTLR4-powered
+First, the source code of \eolang{} is parsed by ANTLR4-powered
parser and an intermediate representation is built in XML,
-as was demonstrated in the Section~\ref{sec:xml}.
-The output format is called \XMIR{}.
+as was demonstrated in \cref{sec:xml}.
+The output format is called \xmir{}.
One \ff{.eo} file with
-the source code in \eo{} produces one \XMIR{} file with \ff{.xml} extension.
+the source code in \eolang{} produces one \xmir{} file with \ff{.xml} extension.
-\XMIR{} is then refined via a \emph{pipeline} of XSLT stylesheets.
-For example, \XMIR{} at \ref{ln:xml-circle}--\ref{ln:xml-circle-end} contains a
-reference to the object \ff{r} at the line no.\ref{ln:xml-circle-r}.
+\xmir{} is then refined via a \emph{pipeline} of XSLT stylesheets.
+For example, \xmir{} at \lrefs{xml-circle}{xml-circle-end} contains a
+reference to the object \ff{r} at \lref{xml-circle-r}.
An XSL transformation adds an attribute \ff{ref} to the XML element \ff{},
referring it to the line inside XML document, where the object \ff{r} is defined:
\begin{ffcode}
- |$\label{ln:xml-circle2-r}$|
+ (*@\label{ln:xml-circle2-r}@*)
-
+
2
3.14
@@ -23,14 +23,14 @@
\end{ffcode}
There are over two dozens XSL transformations in the pipeline, which
-are applied to the \XMIR{} in a specific order. New transformations can
+are applied to the \xmir{} in a specific order. New transformations can
be added to the pipeline for example in order to detect inconsistencies
-in \XMIR{}, enforce new semantic rules, or optimize object structures.
+in \xmir{}, enforce new semantic rules, or optimize object structures.
-Then, \XMIR{} can be translated to machine code, bytecode, C++ source code,
+Then, \xmir{} can be translated to machine code, bytecode, C++ source code,
or any other target platform language. We implemented
a translator to Java source code, which represents
-\XMIR{} objects as Java classes and attributes as pairs in encapsulated
+\xmir{} objects as Java classes and attributes as pairs in encapsulated
\ff{java.util.HashMap} instances.
Then, Java source code is compiled to bytecode by OpenJDK Java compiler.
diff --git a/paper/sections/related.tex b/paper/sections/related.tex
index a4526c5608..22a1c13db8 100644
--- a/paper/sections/related.tex
+++ b/paper/sections/related.tex
@@ -5,7 +5,7 @@
by~\citet{gordon1998concurrent} to support concurrency and synchronisation,
and by~\citet{jeffrey1999distributed} to support distributed programming.
-Earlier, \citet{honda1991object} combined OOP and $\pi$-calculus in order to
+Earlier, \citet{honda1991object} combined OOP and \(\pi\)-calculus in order to
introduce object calculus for asynchronous communication, which was further
referenced by~\citet{jones1993pi} in their work on object-based design notation.
diff --git a/paper/sections/semantics.tex b/paper/sections/semantics.tex
index 89d5c68fe0..fccbaece8f 100644
--- a/paper/sections/semantics.tex
+++ b/paper/sections/semantics.tex
@@ -10,55 +10,55 @@
\subsection{Object Graph}\label{ssec:graph}
Consider the object from \lrefs{book2}{book2-end},
-which is also represented by the expression in Eq.~\ref{eq:book}.
-Fig.~\ref{fig:book2} represents it as a graph.
+which is also represented by the expression in \cref{eq:book}.
+\Cref{fig:book2} represents it as a graph.
\begin{figure}[t!]
\begin{phigure}
- \node[object] (v0) {$\Phi$};
- \node[object] (v2) [below right=0.5cm and 1.8cm of v0] {$v_2$};
+ \node[object] (v0) {\(\Phi\)};
+ \node[object] (v2) [below right=0.5cm and 1.8cm of v0] {\(v_2\)};
\draw (v0) -- pic[sloped,rho]{parallel arrow={0.3,-0.15}} (v2) node [attr] {\ff{book2}};
- \node[atom] (v1) [below left of=v0] {$v_1$} node[lambda] at (v1.south east) {$M_1$};
+ \node[atom] (v1) [below left of=v0] {\(v_1\)} node[lambda] at (v1.south east) {\(M_1\)};
\draw (v0) -- pic[sloped,rho]{parallel arrow={-0.3,-0.15}} (v1) node [attr] {\ff{memory}};
- \draw[ref] (v2) -- (v1) node [attr] {\ff{price}} node [locator] {$\Phi.\ff{memory}$};
- \node[object] (v4) [below left=1.5cm and 0.5cm of v2] {$v_4$};
+ \draw[ref] (v2) -- (v1) node [attr] {\ff{price}} node [locator] {\(\Phi.\ff{memory}\)};
+ \node[object] (v4) [below left=1.5cm and 0.5cm of v2] {\(v_4\)};
\draw (v2) -- pic[sloped,rho]{parallel arrow={-0.3,-0.15}} (v4) node [attr] {\ff{title}};
- \node[empty] (v3) [below right=1cm and 1cm of v2] {$v_3$};
+ \node[empty] (v3) [below right=1cm and 1cm of v2] {\(v_3\)};
\draw (v2) -- pic[sloped,rho]{parallel arrow={0.3,-0.15}} (v3) node [attr] {\ff{isbn}};
- \node[data] (d4) [below left=0.5cm and 1.5cm of v4] {$d_4$};
- \draw (v4) -- pic[sloped,rho]{parallel arrow={-0.3,-0.15}} (d4) node [attr] {$\Delta$};
+ \node[data] (d4) [below left=0.5cm and 1.5cm of v4] {\(d_4\)};
+ \draw (v4) -- pic[sloped,rho]{parallel arrow={-0.3,-0.15}} (d4) node [attr] {\(\Delta\)};
\node [anchor=south east] at (current bounding box.south east) {
\begin{minipage}{15em}\raggedleft
- $d_{4} \to \ff{"Object Thinking"}$
+ \(d_{4} \to \ff{"Object Thinking"}\)
\end{minipage}};
\end{phigure}
-\figcap{The object graph with a few objects from Eq.~\ref{eq:book2}, where
-$d_4$ is \ff{"Object Thinking"} data and $M_1$ is a lambda expression defined
+\figcap{The object graph with a few objects from \cref{eq:book2}, where
+\(d_4\) is \ff{"Object Thinking"} data and \(M_1\) is a lambda expression defined
in the runtime.}
\label{fig:book2}
\end{figure}
-The vertice at the top of the graph is the ``root'' object (see Def.~\ref{def:locator}),
-where all other objects that are not anonymous (see Def.~\ref{def:parent}) are bound to.
-The vertice $v_2$ is the abstract object \ff{book2}. The name of the object within the
-scope of $\Phi$ is the label on the edge from $\Phi$ to $v_2$. The labeled edge
-between $v_2$ and $v_3$ makes the object $v_3$ an attribute of $v_2$ with the
-identifier \ff{isbn}. Even though the object $v_3$ is $\varnothing$, the graph
+The vertice at the top of the graph is the ``root'' object (see \cref{def:locator}),
+where all other objects that are not anonymous (see \cref{def:parent}) are attached to.
+The vertice \(v_2\) is the abstract object \ff{book2}. The name of the object within the
+scope of \(\Phi\) is the label on the edge from \(\Phi\) to \(v_2\). The labeled edge
+between \(v_2\) and \(v_3\) makes the object \(v_3\) an attribute of \(v_2\) with the
+identifier \ff{isbn}. Even though the object \(v_3\) is \(\varnothing\), the graph
depicts it as any other object.
-The rectangle attached to the vertice $v_1$ makes it an atom (see Def.~\ref{def:atom})
-and $M_1$, the content of the rectangle, is its $\lambda$-term. Atoms
-are depicted with double-lined circles. The data $d_4$
-attached to the vertice $v_4$ by the named edge $\Delta$
+The rectangle attached to the vertice \(v_1\) makes it an atom (see \cref{def:atom})
+and \(M_1\), the content of the rectangle, is its \(\lambda\)-term. Atoms
+are depicted with double-lined circles. The data \(d_4\)
+attached to the vertice \(v_4\) by the named edge \(\Delta\)
is the text \ff{"Object Thinking"}.
There are six graphical elements that may be present on an object graph:
A \emph{circle} with a name inside it is an object.
A \emph{named edge} from a circle to another circle is an attribute of the departing object.
-A \emph{snake} edge is the $\rho$ attribute.
+A \emph{snake} edge is the \(\rho\) attribute.
A \emph{dotted} edge connects a copy with the origin.
A \emph{double-bordered} circle is an atom.
-A \emph{rectangle} attached to a circle contains the $\lambda$-term of the atom.
+A \emph{rectangle} attached to a circle contains the \(\lambda\)-term of the atom.
\subsection{SODG}
@@ -74,126 +74,126 @@ \subsection{SODG}
\makeatother
\begin{tabbing}
\hspace*{2.6cm}\= \kill
-$\ff{ADD}(v_1)$
+\(\ff{ADD}(v_1)\)
\>
- \tabfill{Adds a new vertice $v_1$ to the graph:}
+ \tabfill{Adds a new vertice \(v_1\) to the graph:}
\\
\>
\begin{phigure}
- \node[object] (v1) {$v_1$};
+ \node[object] (v1) {\(v_1\)};
\end{phigure}
\\
-$\ff{BIND}(e_1, v_1, v_2, a)$
+\(\ff{BIND}(e_1, v_1, v_2, a)\)
\>
- \tabfill{Adds a solid uni-directed edge $e_1$ labeled as $a$ from an existing vertice $v_1$ to an existing vertice $v_2$,
- making a snake edge if $a$ equals to $\rho$ and adding a reverse snake edge otherwise:}
+ \tabfill{Adds a solid uni-directed edge \(e_1\) labeled as \(a\) from an existing vertice \(v_1\) to an existing vertice \(v_2\),
+ making a snake edge if \(a\) equals to \(\rho\) and adding a reverse snake edge otherwise:}
\\
\> \begin{phigure}
- \node[object] (v1) {$v_1$};
- \node[object, right of=v1] (v2) {$v_2$};
- \draw (v1) -- pic[sloped,rho]{parallel arrow={0.3,-0.15}} (v2) node [attr] {$a$} node [edge-name] {$e_1$};
+ \node[object] (v1) {\(v_1\)};
+ \node[object, right of=v1] (v2) {\(v_2\)};
+ \draw (v1) -- pic[sloped,rho]{parallel arrow={0.3,-0.15}} (v2) node [attr] {\(a\)} node [edge-name] {\(e_1\)};
\end{phigure}
\\
-$\ff{DOT}(e_1, m, v_3, e_2)$
+\(\ff{DOT}(e_1, m, v_3, e_2)\)
\>
- \tabfill{Deletes the edge $e_1$ going from $v_1$ to $v_2$,
- adding a new atom vertice $v_3$,
- connecting $v_1$ to $v_3$ with an edge $e_2$ labeled the same way as $e_1$,
- connecting $v_3$ and $v_2$ with an edge labeled as \ff{t},
+ \tabfill{Deletes the edge \(e_1\) going from \(v_1\) to \(v_2\),
+ adding a new atom vertice \(v_3\),
+ connecting \(v_1\) to \(v_3\) with an edge \(e_2\) labeled the same way as \(e_1\),
+ connecting \(v_3\) and \(v_2\) with an edge labeled as \ff{t},
and
- attaching a rectangle with a special lambda expression to $v_3$:}
+ attaching a rectangle with a special lambda expression to \(v_3\):}
\\
\> \begin{phigure}
- \node[object] (v1) {$v_1$};
- \node[object, right=0.8cm of v1] (v2) {$v_2$};
- \draw (v1) -- (v2) node [attr] {$a$} node [edge-name] {$e_1$};
- \node[object, right=1cm of v2] (v1d) {$v_1$};
+ \node[object] (v1) {\(v_1\)};
+ \node[object, right=0.8cm of v1] (v2) {\(v_2\)};
+ \draw (v1) -- (v2) node [attr] {\(a\)} node [edge-name] {\(e_1\)};
+ \node[object, right=1cm of v2] (v1d) {\(v_1\)};
\node[transforms, right=0.3cm of v2] {};
- \node[object, right=0.5cm of v1d] (v2d) {$v_2$};
- \node[atom, below=0.8cm of v1d] (v3) {$v_3$}
- node[lambda] at (v3.south east) {$\mathbb{R}(\xi.\ff{t}, m, s)$};
- \draw (v1d) -- (v3) node [attr] {$a$} node [edge-name] {$e_2$};
+ \node[object, right=0.5cm of v1d] (v2d) {\(v_2\)};
+ \node[atom, below=0.8cm of v1d] (v3) {\(v_3\)}
+ node[lambda] at (v3.south east) {\(\mathbb{R}(\xi.\ff{t}, m, s)\)};
+ \draw (v1d) -- (v3) node [attr] {\(a\)} node [edge-name] {\(e_2\)};
\draw (v3) -- (v2d) node [attr] {\ff{t}};
\end{phigure}
\\
-$\ff{COPY}(e_1, v_3, e_2)$
+\(\ff{COPY}(e_1, v_3, e_2)\)
\>
- \tabfill{Reconnects the edge $e_1$ going from $v_1$ to $v_2$,
- adding a new vertice $v_3$,
- connecting $v_1$ and $v_3$ with edge $e_1$,
- and connecting $v_3$ and $v_2$ with a new dotted edge $e_2$:}
+ \tabfill{Reconnects the edge \(e_1\) going from \(v_1\) to \(v_2\),
+ adding a new vertice \(v_3\),
+ connecting \(v_1\) and \(v_3\) with edge \(e_1\),
+ and connecting \(v_3\) and \(v_2\) with a new dotted edge \(e_2\):}
\\
\> \begin{phigure}
- \node[object] (v1) {$v_1$};
- \node[object, right=0.8cm of v1] (v2) {$v_2$};
- \draw (v1) -- (v2) node [attr] {$a$} node [edge-name] {$e_1$};
- \node[object, right=1cm of v2] (v1d) {$v_1$};
+ \node[object] (v1) {\(v_1\)};
+ \node[object, right=0.8cm of v1] (v2) {\(v_2\)};
+ \draw (v1) -- (v2) node [attr] {\(a\)} node [edge-name] {\(e_1\)};
+ \node[object, right=1cm of v2] (v1d) {\(v_1\)};
\node[transforms, right=0.3cm of v2] {};
- \node[object, right=0.7cm of v1d] (v2d) {$v_2$};
- \node[object, below right=0.8cm and 0.2cm of v1d] (v3) {$v_3$};
- \draw (v1d) -- (v3) node [attr] {$a$} node [edge-name] {$e_1$};
- \draw[parent] (v3) -- (v2d) node [edge-name] {$e_2$};
+ \node[object, right=0.7cm of v1d] (v2d) {\(v_2\)};
+ \node[object, below right=0.8cm and 0.2cm of v1d] (v3) {\(v_3\)};
+ \draw (v1d) -- (v3) node [attr] {\(a\)} node [edge-name] {\(e_1\)};
+ \draw[parent] (v3) -- (v2d) node [edge-name] {\(e_2\)};
\end{phigure}
\\
-$\ff{ATOM}(v_1, M_1)$
+\(\ff{ATOM}(v_1, M_1)\)
\>
- \tabfill{Attaches a rectangle to an existing vertice $v_1$ with a lambda expression $M_1$ inside
- and adds the second border to $v_1$:}
+ \tabfill{Attaches a rectangle to an existing vertice \(v_1\) with a lambda expression \(M_1\) inside
+ and adds the second border to \(v_1\):}
\\
\> \begin{phigure}
- \node[object] (v1) {$v_1$};
+ \node[object] (v1) {\(v_1\)};
\node[transforms, right=0.3cm of v1] {};
- \node[atom, right=1cm of v1] (v1d) {$v_1$};
- \node[lambda] at (v1d.south east) {$M_1$};
+ \node[atom, right=1cm of v1] (v1d) {\(v_1\)};
+ \node[lambda] at (v1d.south east) {\(M_1\)};
\end{phigure}
\\
-$\ff{DATA}(v_1, \Gamma)$
+\(\ff{DATA}(v_1, \Gamma)\)
\>
- \tabfill{Changes the shape of an existing vertice $v_1$ to a polygon and sets its data to $\Gamma$:}
+ \tabfill{Changes the shape of an existing vertice \(v_1\) to a polygon and sets its data to \(\Gamma\):}
\\
\> \begin{phigure}
- \node[object] (v1) {$v_1$};
+ \node[object] (v1) {\(v_1\)};
\node[transforms, right=0.3cm of v1] {};
- \node[data, right=1cm of v1] (v1d) {$\Gamma$};
+ \node[data, right=1cm of v1] (v1d) {\(\Gamma\)};
\end{phigure}
\\
-$\ff{REF}(e_1, v_1, k, a)$
+\(\ff{REF}(e_1, v_1, k, a)\)
\>
- \tabfill{Starting from the vertice $v_1$,
- finds a vertice $v_2$ by the locator $k$
- and links them with an edge $e_1$ named as $a$ with a supplementary label $k$
- (omitting the circle around the vertice $v_2$ is a visual
- trick that helps avoid a long arrow, which would need to be drawn from $v_1$ to the
- found $v_2$ otherwise):}
+ \tabfill{Starting from the vertice \(v_1\),
+ finds a vertice \(v_2\) by the locator \(k\)
+ and links them with an edge \(e_1\) named as \(a\) with a supplementary label \(k\)
+ (omitting the circle around the vertice \(v_2\) is a visual
+ trick that helps avoid a long arrow, which would need to be drawn from \(v_1\) to the
+ found \(v_2\) otherwise):}
\\
\> \begin{phigure}
- \node[object] (v1) {$v_1$};
- \node[dup, right of=v1] (v2) {$v_2$};
- \draw[ref] (v1) -- (v2) node [attr] {$a$} node [locator] {$k$} node [edge-name] {$e_1$};
+ \node[object] (v1) {\(v_1\)};
+ \node[dup, right of=v1] (v2) {\(v_2\)};
+ \draw[ref] (v1) -- (v2) node [attr] {\(a\)} node [locator] {\(k\)} node [edge-name] {\(e_1\)};
\end{phigure}
\\
\end{tabbing}
All SODGs are idempotent, meaning that they have no additional effect
if they are called more than once with the same input parameters.
-The object graph at Fig.~\ref{fig:book2} may be generated with the
+The object graph at \cref{fig:book2} may be generated with the
following ordered sequence of SODGs:
\begin{twocols}
\begin{ffcode}
-ADD(|$\Phi$|)
-ADD(|$v_1$|);
-ATOM(|$v_1$|, |$M_1$|);
-BIND(|$\Phi$|, |$v_1$|, memory);
-ADD(|$v_2$|);
-BIND(|$\Phi$|, |$v_2$|, book2);
-ADD(|$v_3$|);
-BIND(|$v_2$|, |$v_3$|, isbn);
-ADD(|$v_4$|);
-BIND(|$v_2$|, |$v_4$|, title);
-REF(e, |$v_2$|, |$\Phi$|.memory, price);
-ADD(|$d_4$|);
-BIND(|$v_4$|, |$d_4$|, |$\Delta$|);
+ADD((*@\(\Phi\)@*))
+ADD((*@\(v_1@\)*));
+ATOM((*@\(v_1\)@*), (*@\(M_1\)@*));
+BIND((*@\(\Phi\)@*), (*@\(v_1\)@*), memory);
+ADD((*@\(v_2\)@*));
+BIND((*@\(\Phi\)@*), (*@\(v_2\)@*), book2);
+ADD((*@\(v_3\)@*));
+BIND((*@\(v_2\)@*), (*@\(v_3\)@*), isbn);
+ADD((*@\(v_4\)@*));
+BIND((*@\(v_2\)@*), (*@\(v_4\)@*), title);
+REF(e, (*@\(v_2\)@*), (*@\(\Phi\)@*).memory, price);
+ADD((*@\(d_4\)@*));
+BIND((*@\(v_4\)@*), (*@\(d_4\)@*), (*@\(\Delta\)@*));
\end{ffcode}
\end{twocols}
@@ -213,13 +213,13 @@ \subsection{Transformation Rules}
\jrule{abstract}
\end{equation*}
-The $v|E$ notation at the premise part of the rule
-means ``$E$ stands while the focus is at $v$,'' where
-$E$ is an expression and $v$ is an element of the graph, for example a vertice or an edge.
+The \(v|E\) notation at the premise part of the rule
+means ``\(E\) stands while the focus is at \(v\),'' where
+\(E\) is an expression and \(v\) is an element of the graph, for example a vertice or an edge.
The hierarchical vertice indexing notation is used in order to
avoid duplication of indexes. Thus, the index of the vertice
-$v_{i\rr x\rr 1}$ is unique on the graph. The symbol ``$\rr$'' is used
+\(v_{i\rr x\rr 1}\) is unique on the graph. The symbol ``\(\rr\)'' is used
as a delimiter between parts of the index. We decided to use this symbol
instead of a more traditional dot because the semantic of the dot
is already occupied by the dot notation in \phic{}.
@@ -229,10 +229,10 @@ \subsection{Transformation Rules}
be used to denote vertices and edges, being incremented sequentially
in order to avoid duplication.
-Consider for example the abstract object bound to the attribute \ff{is-inside} in Eq.~\ref{eq:c-empty}.
-The premise $v_5|E$ will stand when the focus is at the vertice representing the object \ff{circle},
-where $v_5$ would be the vertice of it (the numbers
-$5$ and $12$ don't mean anything and are just placeholders):
+Consider for example the abstract object attached to the attribute \ff{is-inside} in \cref{eq:c-empty}.
+The premise \(v_5|E\) will stand when the focus is at the vertice representing the object \ff{circle},
+where \(v_5\) would be the vertice of it (the numbers
+\(5\) and \(12\) don't mean anything and are just placeholders):
\begin{equation*}
\dfrac
{\quad v_5 | \ohat{x}{\ff{is-inside}}(\ohat{a_1}{\ff{p}}) \mapsto \llbracket \ohat{E}{\varphi \mapsto \dots} \rrbracket}
@@ -246,17 +246,17 @@ \subsection{Transformation Rules}
on an object graph:
\begin{center}\begin{phigure}
- \node[object] (v5) {$v_5$};
+ \node[object] (v5) {\(v_5\)};
\node[transforms, right=0.3cm of v5] {};
- \node[object, right=1cm of v5] (v5d) {$v_5$};
- \node[object, below right=0.6cm and 1.5cm of v5d] (v12) {$v_{12}$};
+ \node[object, right=1cm of v5] (v5d) {\(v_5\)};
+ \node[object, below right=0.6cm and 1.5cm of v5d] (v12) {\(v_{12}\)};
\draw (v5d) -- pic[sloped,rho]{parallel arrow={0.3,-0.15}} (v12) node [attr] {\ff{is-inside}};
- \node[object, below left=1cm of v12] (v13) {$v_{13}$};
+ \node[object, below left=1cm of v12] (v13) {\(v_{13}\)};
\draw (v12) -- pic[sloped,rho]{parallel arrow={0.3,-0.15}} (v13) node [attr] {\ff{p}};
\end{phigure}\end{center}
-The $E$ part of the premise is the internals of the abstract object \ff{is-inside}.
-It will be processed by one of the rules, while looking at $v_{12}$.
+The \(E\) part of the premise is the internals of the abstract object \ff{is-inside}.
+It will be processed by one of the rules, while looking at \(v_{12}\).
\rrule{comma} explains how a comma-separated series of expressions break
into individual rules (since the expression inside \ff{is-inside} is the only
one, this rule is not applicable):
@@ -276,21 +276,21 @@ \subsection{Transformation Rules}
{\ff{REF}(e_{i\rr a}, v_i,x,a) \quad v_i|x \quad e_{i\rr a}|E}
\jrule{attribute}
\end{equation*}
-The notation ``$x \; E$'' in the premise of \rrule{attribute} splits the expression
+The notation ``\(x \; E\)'' in the premise of \rrule{attribute} splits the expression
under consideration into two parts: the ``head'' of a single identifier
-$x$ and the ``tail'' of the expression as $E$.
-In the conclusion part of the rule a vertice is found using the locator $x$
+\(x\) and the ``tail'' of the expression as \(E\).
+In the conclusion part of the rule a vertice is found using the locator \(x\)
and then a new edge is added, starting from the current vertice and arriving
-to the vertice found. Strictly, $x$ must be a single identifier. However,
+to the vertice found. Strictly, \(x\) must be a single identifier. However,
in a more relaxed mode it is possible to have a longer locator as the head
-of the expression. For example, the expression $\rho.\rho.\ff{p}$ can be split
-strictly on $\rho$ as the head and $\rho.\ff{p}$ as the tail; but it
-also can be split on $\rho.\rho$ as the head and $\ff{p}$ as the tail. Longer
+of the expression. For example, the expression \(\rho.\rho.\ff{p}\) can be split
+strictly on \(\rho\) as the head and \(\rho.\ff{p}\) as the tail; but it
+also can be split on \(\rho.\rho\) as the head and \(\ff{p}\) as the tail. Longer
locators in the head part of the expression are only allowed if the vertice
they refer to already exists on the graph.
-\rrule{attribute} also processes $x$ in the conclusion part,
+\rrule{attribute} also processes \(x\) in the conclusion part,
providing other rules the opportunity to deal with it.
-In particular, \rrule{data} may process $x$ if it is data.
+In particular, \rrule{data} may process \(x\) if it is data.
The tranformation of the internals of \ff{is-inside} with \rrule{attribute}
would look like the following:
@@ -299,25 +299,25 @@ \subsection{Transformation Rules}
{v_{12} | \ohat{a}{\varphi} \mapsto \ohat{x}{\rho} \; \ohat{E}{.\ff{distance}(\ff{p}).\ff{lte}(\ff{radius})}}
{\ff{REF}(e_{14}, v_{12},v_{5},\varphi) \quad e_{14}|.\ff{distance}(\ff{p}).\ff{lte}(\ff{radius})}
\end{equation*}
-Here $\rho$ represents the $x$ part of the premise and the expression
-that starts with a dot represents the $E$ part. At the conclusion,
-$x$ is being replaced with $v_5$, because $\rho$ from the vertice $v_{12}$ points
-to it: it is the parent object of $v_{12}$. The edge $e_{14}$ created by the \ff{REF}
+Here \(\rho\) represents the \(x\) part of the premise and the expression
+that starts with a dot represents the \(E\) part. At the conclusion,
+\(x\) is being replaced with \(v_5\), because \(\rho\) from the vertice \(v_{12}\) points
+to it: it is the parent object of \(v_{12}\). The edge \(e_{14}\) created by the \ff{REF}
is used in the expression that finishes the conclusion, triggering the processing
-of the tail part of the formula: the head is the $\rho$, while the tail
+of the tail part of the formula: the head is the \(\rho\), while the tail
is the dot and everything that goes after it.
Visually, the execution of \rrule{attribute} would produce the following
-changes on the object graph (the vertice $v_{13}$ is not shown for the sake of brevity):
+changes on the object graph (the vertice \(v_{13}\) is not shown for the sake of brevity):
\begin{center}\begin{phigure}
- \node[object] (v5) {$v_5$};
- \node[object, below right=1cm and 1.1cm of v5] (v12) {$v_{12}$};
+ \node[object] (v5) {\(v_5\)};
+ \node[object, below right=1cm and 1.1cm of v5] (v12) {\(v_{12}\)};
\draw (v5) -- pic[sloped,rho]{parallel arrow={0.3,-0.15}} (v12) node [attr] {\ff{is-inside}};
\node[transforms, right=1.4cm of v5] {};
- \node[object, right=2.4cm of v5] (v5d) {$v_5$};
- \node[object, below right=1cm and 1.1cm of v5d] (v12d) {$v_{12}$};
+ \node[object, right=2.4cm of v5] (v5d) {\(v_5\)};
+ \node[object, below right=1cm and 1.1cm of v5d] (v12d) {\(v_{12}\)};
\draw (v5d) -- pic[sloped,rho]{parallel arrow={0.3,-0.15}} (v12d) node [attr] {\ff{is-inside}};
- \draw (v12d) edge [bend right=50] node [attr] {$\varphi$} node [edge-name] {$e_{14}$} (v5d);
+ \draw (v12d) edge [bend right=50] node [attr] {\(\varphi\)} node [edge-name] {\(e_{14}\)} (v5d);
\end{phigure}\end{center}
The dot notation is resolved by \rrule{dot}, which unlike previously
@@ -328,7 +328,7 @@ \subsection{Transformation Rules}
{\ff{DOT}(e_i, x, v_{i\rr x}, e_{i\rr x\rr 1}) \quad e_{i\rr x\rr 1}|E}
\jrule{dot}
\end{equation*}
-Here $x$ is the identifier that goes after the dot and $E$ is everything
+Here \(x\) is the identifier that goes after the dot and \(E\) is everything
else, the tail of the expression. In this example, the instance
of the rule would look like this:
\begin{equation*}
@@ -340,17 +340,17 @@ \subsection{Transformation Rules}
modifications on the object graph:
\begin{center}\begin{phigure}
- \node[object] (v5) {$v_5$};
- \node[object, below right=1cm and 1.1cm of v5] (v12) {$v_{12}$};
+ \node[object] (v5) {\(v_5\)};
+ \node[object, below right=1cm and 1.1cm of v5] (v12) {\(v_{12}\)};
\draw (v5) -- pic[sloped,rho]{parallel arrow={0.3,-0.15}} (v12) node [attr] {\ff{is-inside}};
- \draw (v12) edge [bend right=50] node [attr] {$\varphi$} node [edge-name] {$e_{14}$} (v5);
+ \draw (v12) edge [bend right=50] node [attr] {\(\varphi\)} node [edge-name] {\(e_{14}\)} (v5);
\node[transforms, right=1.3cm of v5] {};
- \node[object,right=2cm of v5] (v5d) {$v_5$};
- \node[object, below right=1cm and 1.1cm of v5d] (v12d) {$v_{12}$};
+ \node[object,right=2cm of v5] (v5d) {\(v_5\)};
+ \node[object, below right=1cm and 1.1cm of v5d] (v12d) {\(v_{12}\)};
\draw (v5d) -- pic[sloped,rho]{parallel arrow={0.3,-0.15}} (v12d) node [attr] {\ff{is-inside}};
- \node[atom, above right=1cm and 0cm of v12d] (v15) {$v_{15}$}
- node[lambda] at (v15.south east) {$\mathbb{R}(\xi.\ff{t}, \ff{distance}, s)$};
- \draw (v12d) -- (v15) node [attr] {$\varphi$} node [edge-name] {$e_{16}$};
+ \node[atom, above right=1cm and 0cm of v12d] (v15) {\(v_{15}\)}
+ node[lambda] at (v15.south east) {\(\mathbb{R}(\xi.\ff{t}, \ff{distance}, s)\)};
+ \draw (v12d) -- (v15) node [attr] {\(\varphi\)} node [edge-name] {\(e_{16}\)};
\draw (v15) -- (v5d) node [attr] {\ff{t}};
\end{phigure}\end{center}
@@ -373,22 +373,22 @@ \subsection{Transformation Rules}
Visually, this rule would produce the following modifications on the graph:
\begin{center}\begin{phigure}
- \node[object] (v12) {$v_{12}$};
- \node[atom, above right=1cm and 0cm of v12] (v15) {$v_{15}$}
- node[lambda] at (v15.south east) {$M_{15}$};
- \draw (v12) -- (v15) node [attr] {$\varphi$} node [edge-name] {$e_{16}$};
+ \node[object] (v12) {\(v_{12}\)};
+ \node[atom, above right=1cm and 0cm of v12] (v15) {\(v_{15}\)}
+ node[lambda] at (v15.south east) {\(M_{15}\)};
+ \draw (v12) -- (v15) node [attr] {\(\varphi\)} node [edge-name] {\(e_{16}\)};
\node[transforms, right=1cm of v15] {};
- \node[object, right=2cm of v12] (v12d) {$v_{12}$};
- \node[atom, above right=1cm and 0cm of v12d] (v15d) {$v_{15}$}
- node[lambda] at (v15d.south east) {$M_{15}$};
- \draw (v12) -- (v15) node [attr] {$\varphi$} node [edge-name] {$e_{16}$};
- \node[object, above right=0cm and 1.5cm of v12d] (v17) {$v_{17}$};
- \draw (v12d) -- (v17) node [attr] {$\varphi$} node [edge-name] {$e_{16}$};
- \draw[parent] (v17) edge [bend right=30] node [edge-name] {$e_{18}$} (v15d);
+ \node[object, right=2cm of v12] (v12d) {\(v_{12}\)};
+ \node[atom, above right=1cm and 0cm of v12d] (v15d) {\(v_{15}\)}
+ node[lambda] at (v15d.south east) {\(M_{15}\)};
+ \draw (v12) -- (v15) node [attr] {\(\varphi\)} node [edge-name] {\(e_{16}\)};
+ \node[object, above right=0cm and 1.5cm of v12d] (v17) {\(v_{17}\)};
+ \draw (v12d) -- (v17) node [attr] {\(\varphi\)} node [edge-name] {\(e_{16}\)};
+ \draw[parent] (v17) edge [bend right=30] node [edge-name] {\(e_{18}\)} (v15d);
\end{phigure}\end{center}
The last rule deals with data, such as integers, string literals, and so on
-(together referred to as $\Gamma$):
+(together referred to as \(\Gamma\)):
\begin{equation*}
\dfrac
{v_i | \Gamma}
@@ -405,22 +405,22 @@ \subsection{Transformation Rules}
\jrule{lambda}
\end{equation*}
Visually, the rule would produce the following modifications on the graph
-for Eq.~\ref{def:stdout}:
+for \cref{def:stdout}:
\begin{center}\begin{phigure}
- \node[object] (phi) {$\Phi$};
- \node[object, below right=1cm of phi] (v1) {$v_{1}$};
+ \node[object] (phi) {\(\Phi\)};
+ \node[object, below right=1cm of phi] (v1) {\(v_{1}\)};
\draw (phi) -- (v1) node [attr] {\ff{stdout}};
\node[transforms, right=1cm of phi] {};
- \node[object, right=2cm of phi] (phi-d) {$\Phi$};
- \node[atom, below right=1cm of phi-d] (v1d) {$v_{1}$}
- node[lambda] at (v1d.south east) {$M_\text{stdout}$};
+ \node[object, right=2cm of phi] (phi-d) {\(\Phi\)};
+ \node[atom, below right=1cm of phi-d] (v1d) {\(v_{1}\)}
+ node[lambda] at (v1d.south east) {\(M_\text{stdout}\)};
\draw (phi-d) -- (v1d) node [attr] {\ff{stdout}};
\end{phigure}\end{center}
-In order to demonstrate a larger example, Fig.~\ref{fig:is} shows
+In order to demonstrate a larger example, \cref{fig:is} shows
an object graph, which the described rules
-would generate by transforming the object \ff{is} from Eq.~\ref{eq:is}.
+would generate by transforming the object \ff{is} from \cref{eq:is}.
\subsection{Dataization}
@@ -433,197 +433,197 @@ \subsection{Dataization}
it knows how to calculate it. Once being asked to turn itself into
data it will ask all its three inner object the same question:
``What data you represent?'' They are integers and will return the
-data they have attached to their attributes $\Delta$. Then, the object
-\ff{sum}, using its $\lambda$-term, will calculate the arithmetic
+data they have attached to their attributes \(\Delta\). Then, the object
+\ff{sum}, using its \(\lambda\)-term, will calculate the arithmetic
sum of the numbers returned by its inner objects.
Visually, the object \ff{sum} from \lref{sum-instance} may be represented
by the following object graph:
\begin{center}\begin{phigure}
- \node[object] (v0) {$\Phi$};
- \node[atom, below right=1cm of v0] (v1) {$v_{1}$}
- node[lambda] at (v1.south east) {$\sum a_i$};
+ \node[object] (v0) {\(\Phi\)};
+ \node[atom, below right=1cm of v0] (v1) {\(v_{1}\)}
+ node[lambda] at (v1.south east) {\(\sum a_i\)};
\draw (v0) -- pic[sloped,rho]{parallel arrow={0.3,-0.15}} (v1) node [attr] {\ff{sum}};
- \node[object, above right=1.2cm and 2.8cm of v1] (v2) {$v_{2}$};
+ \node[object, above right=1.2cm and 2.8cm of v1] (v2) {\(v_{2}\)};
\draw[parent] (v2) edge [bend right=30] (v1);
- \node[object, below left=1cm of v2] (v3) {$v_{3}$};
- \draw (v2) -- pic[sloped,rho]{parallel arrow={-0.3,-0.15}} (v3) node [attr] {$a_1$};
+ \node[object, below left=1cm of v2] (v3) {\(v_{3}\)};
+ \draw (v2) -- pic[sloped,rho]{parallel arrow={-0.3,-0.15}} (v3) node [attr] {\(a_1\)};
\node[data, below=0.7cm of v3] (d3) {\ff{8}};
- \draw (v3) -- pic[sloped,rho]{parallel arrow={0.3,-0.15}} (d3) node [attr] {$\Delta$};
- \node[object, below=1cm of v2] (v4) {$v_{4}$};
- \draw (v2) -- pic[sloped,rho]{parallel arrow={0.3,-0.15}} (v4) node [attr] {$a_2$};
+ \draw (v3) -- pic[sloped,rho]{parallel arrow={0.3,-0.15}} (d3) node [attr] {\(\Delta\)};
+ \node[object, below=1cm of v2] (v4) {\(v_{4}\)};
+ \draw (v2) -- pic[sloped,rho]{parallel arrow={0.3,-0.15}} (v4) node [attr] {\(a_2\)};
\node[data, below=0.7cm of v4] (d4) {\ff{13}};
- \draw (v4) -- pic[sloped,rho]{parallel arrow={-0.3,-0.15}} (d4) node [attr] {$\Delta$};
- \node[object, below right=1cm of v2] (v5) {$v_{5}$};
- \draw (v2) -- pic[sloped,rho]{parallel arrow={0.3,-0.15}} (v5) node [attr] {$a_3$};
+ \draw (v4) -- pic[sloped,rho]{parallel arrow={-0.3,-0.15}} (d4) node [attr] {\(\Delta\)};
+ \node[object, below right=1cm of v2] (v5) {\(v_{5}\)};
+ \draw (v2) -- pic[sloped,rho]{parallel arrow={0.3,-0.15}} (v5) node [attr] {\(a_3\)};
\node[data, below=0.7cm of v5] (d5) {\ff{-9}};
- \draw (v5) -- pic[sloped,rho]{parallel arrow={-0.3,-0.15}} (d5) node [attr] {$\Delta$};
+ \draw (v5) -- pic[sloped,rho]{parallel arrow={-0.3,-0.15}} (d5) node [attr] {\(\Delta\)};
\end{phigure}\end{center}
-The dataization of $v_2$, which is an anonymous copy of \ff{sum} with
-three arguments $v_3$, $v_4$, and $v_5$, would produce an arithmetic
-sum of three integers calculated by the $\lambda$-term of $v_1$.
+The dataization of \(v_2\), which is an anonymous copy of \ff{sum} with
+three arguments \(v_3\), \(v_4\), and \(v_5\), would produce an arithmetic
+sum of three integers calculated by the \(\lambda\)-term of \(v_1\).
We suggest the following recursive object discovery
-algorithm, which finds a vertice in a graph by its locator $k$ and
-returns a vertice connected to it as an attribute $a$:
+algorithm, which finds a vertice in a graph by its locator \(k\) and
+returns a vertice connected to it as an attribute \(a\):
\begin{twocols}
\begin{algo}
-\kw{function} $\mathbb{R}(k,a,S)$ \\
- \tab $v \gets k$ \\
- \tab \kw{if} $k$ is a locator with a dot inside \\
- \tab\tab $a' \gets$ after the last dot in $k$ \\
- \tab\tab $k' \gets$ before $a'$ in $k$ \\
- \tab\tab $v \gets$ $\mathbb{R}(k', a', S)$ \\
+\kw{function} \(\mathbb{R}(k,a,S)\) \\
+ \tab \(v \gets k\) \\
+ \tab \kw{if} \(k\) is a locator with a dot inside \\
+ \tab\tab \(a' \gets\) after the last dot in \(k\) \\
+ \tab\tab \(k' \gets\) before \(a'\) in \(k\) \\
+ \tab\tab \(v \gets\) \(\mathbb{R}(k', a', S)\) \\
\tab \kw{end if} \\
- \tab \kw{if} $v = \xi$ \kw{then} $v \gets S[0]$ \\
- \tab \kw{if} $v = \rho$ \kw{then} $v \gets S[1]$ \\
- \tab \kw{if} $v$ has $a$-edge to $\tau$ \kw{then} \kw{return} $\tau$ \\
- \tab \kw{if} $v$ has $\varphi$-edge to $\tau$ \kw{then} \kw{return} $\mathbb{R}(\tau, a, \tau + S)$ \\
- \tab \kw{if} $v$ has a dotted edge to $\tau$ \kw{then} \kw{return} $\mathbb{R}(\tau, \xi.a, \tau + S)$ \\
- \tab \kw{if} $v$ has $M$ \kw{then} \kw{return} $\mathbb{R}((\lambda s.M \; v + S), a, S)$ \\
- \tab \kw{return} $\perp$ \\
+ \tab \kw{if} \(v = \xi\) \kw{then} \(v \gets S[0]\) \\
+ \tab \kw{if} \(v = \rho\) \kw{then} \(v \gets S[1]\) \\
+ \tab \kw{if} \(v\) has \(a\)-edge to \(\tau\) \kw{then} \kw{return} \(\tau\) \\
+ \tab \kw{if} \(v\) has \(\varphi\)-edge to \(\tau\) \kw{then} \kw{return} \(\mathbb{R}(\tau, a, \tau + S)\) \\
+ \tab \kw{if} \(v\) has a dotted edge to \(\tau\) \kw{then} \kw{return} \(\mathbb{R}(\tau, \xi.a, \tau + S)\) \\
+ \tab \kw{if} \(v\) has \(M\) \kw{then} \kw{return} \(\mathbb{R}((\lambda s.M \; v + S), a, S)\) \\
+ \tab \kw{return} \(\perp\) \\
\kw{end}
\end{algo}
\end{twocols}
-Here, $S$ is a vector of vertices, while $v+S$ produces a new vector
-where $v$ stays at the first position and all other elements of $S$ follow.
-The notation $S[i]$ denotes the $i$-th element of the vector, while
+Here, \(S\) is a vector of vertices, while \(v+S\) produces a new vector
+where \(v\) stays at the first position and all other elements of \(S\) follow.
+The notation \(S[i]\) denotes the \(i\)-th element of the vector, while
counting starts with zero.
-The notation $(\lambda s.M \; v + S)$ means creating a function from
-the $\lambda$-term $M$ with one parameter $s$ and then calculating
-it with the argument $v + S$.
+The notation \((\lambda s.M \; v + S)\) means creating a function from
+the \(\lambda\)-term \(M\) with one parameter \(s\) and then calculating
+it with the argument \(v + S\).
It is expected that the function returns a locator of a vertice or
the vertice itself, where the locator can be derived as
-the shortest path from $\Phi$ to the given vertice.
-The vector $s$, provided to the
-function as its parameter, is used in $M$ when it is necessary
-to use $\mathbb{R}$ in order to find some object.
+the shortest path from \(\Phi\) to the given vertice.
+The vector \(s\), provided to the
+function as its parameter, is used in \(M\) when it is necessary
+to use \(\mathbb{R}\) in order to find some object.
If a function returns data, which doesn't have a locator, a new vertice
-$v_i$ is created implicitly with the locator $\Phi.v_i$, and
-a single attribute $\Delta$ connected to the data returned, where
-$i$ is the next available index in the graph.
+\(v_i\) is created implicitly with the locator \(\Phi.v_i\), and
+a single attribute \(\Delta\) connected to the data returned, where
+\(i\) is the next available index in the graph.
-For example, $\mathbb{R}(\Phi.\ff{c}.\ff{center}.\ff{y},
-\Delta, \varnothing)$ being executed on the graph presented at the
-Fig.~\ref{fig:is} would return the vertice $d_{21}$, which is $+9$.
+For example, \(\mathbb{R}(\Phi.\ff{c}.\ff{center}.\ff{y},\Delta, \varnothing)\)
+being executed on the graph presented at
+\cref{fig:is} would return the vertice \(d_{21}\), which is \(+9\).
We also define a dataization function, which turns an object into data:
\begin{algo}
-\kw{function} $\mathbb{D}(k)$ \\
- \tab \kw{return} $\mathbb{R}(k, \Delta, \varnothing)$ \\
+\kw{function} \(\mathbb{D}(k)\) \\
+ \tab \kw{return} \(\mathbb{R}(k, \Delta, \varnothing)\) \\
\kw{end}
\end{algo}
-The execution of the function $\mathbb{D}(x)$, where $x$ is the
+The execution of the function \(\mathbb{D}(x)\), where \(x\) is the
``program'' object, leads to the execution of the entire program.
-Program terminates with an error message when $\mathbb{D}(x)$ is $\perp$.
+Program terminates with an error message when \(\mathbb{D}(x)\) is \(\perp\).
\begin{figure*}
\resizebox{.75\textwidth}{!}{
\begin{phigure}
- \node[object] (v0) {$\Phi$};
- \node[object] (v1) [right of=v0] {$v_1$};
+ \node[object] (v0) {\(\Phi\)};
+ \node[object] (v1) [right of=v0] {\(v_1\)};
\draw (v0) -- pic[sloped,rho]{parallel arrow={0.3,-0.15}} (v1) node [attr] {\ff{circle}};
- \node[object] (v2) [below of=v1] {$v_2$};
+ \node[object] (v2) [below of=v1] {\(v_2\)};
\draw (v1) -- pic[sloped,rho]{parallel arrow={0.3,-0.15}} (v2) node [attr] {\ff{center}};
- \node[object] (v3) [below left of=v1] {$v_3$};
+ \node[object] (v3) [below left of=v1] {\(v_3\)};
\draw (v1) -- pic[sloped,rho,auto,swap]{parallel arrow={-0.3,-0.15}} (v3) node [attr] {\ff{radius}};
- \node[object] (v4) [below right of=v1] {$v_4$};
+ \node[object] (v4) [below right of=v1] {\(v_4\)};
\draw (v1) -- pic[sloped,rho]{parallel arrow={0.3,-0.15}} (v4) node [attr] {\ff{is-inside}};
- \node[object] (v6) [below right=1cm of v4] {$v_6$};
+ \node[object] (v6) [below right=1cm of v4] {\(v_6\)};
\draw (v4) -- pic[sloped,rho]{parallel arrow={0.3,-0.15}} (v6) node [attr] {\ff{p}};
- \node[dup] (v2d1) [right=2.1cm of v1] {$v_2$};
- \draw[ref] (v1) -- (v2d1) node [attr] {$\varphi$} node [locator] {$\xi.\ff{center}$};
- \node[atom] (v5) [above right=0.5cm and 3cm of v4] {$v_5$}
- node[lambda] at (v5.south east) {$M_5$};
- \node[dup] (v4d1) [above left=0.5cm of v5] {$v_4$};
+ \node[dup] (v2d1) [right=2.1cm of v1] {\(v_2\)};
+ \draw[ref] (v1) -- (v2d1) node [attr] {\(\varphi\)} node [locator] {\(\xi.\ff{center}\)};
+ \node[atom] (v5) [above right=0.5cm and 3cm of v4] {\(v_5\)}
+ node[lambda] at (v5.south east) {\(M_5\)};
+ \node[dup] (v4d1) [above left=0.5cm of v5] {\(v_4\)};
\draw[rho] (v5) -- (v4d1);
- \node[object] (v25) [below=0.6cm of v5] {$v_{25}$};
+ \node[object] (v25) [below=0.6cm of v5] {\(v_{25}\)};
\draw[parent] (v25) -- (v5);
- \draw (v4) -- pic[sloped,rho]{parallel arrow={0.3,-0.15}} (v25) node [attr] {$\varphi$};
- \node[dup] (v3d1) [below=1.5cm of v25] {$v_3$};
- \draw[ref] (v25) -- (v3d1) node [attr] {\ff{other}} node [locator] {$\rho.\rho.\ff{radius}$};
- \node[atom] (v7) [right=2cm of v5] {$v_7$}
- node[lambda] at (v7.south east) {$M_7$};
- \node[dup] (v5d1) [above left=0.5cm of v7] {$v_5$};
+ \draw (v4) -- pic[sloped,rho]{parallel arrow={0.3,-0.15}} (v25) node [attr] {\(\varphi\)};
+ \node[dup] (v3d1) [below=1.5cm of v25] {\(v_3\)};
+ \draw[ref] (v25) -- (v3d1) node [attr] {\ff{other}} node [locator] {\(\rho.\rho.\ff{radius}\)};
+ \node[atom] (v7) [right=2cm of v5] {\(v_7\)}
+ node[lambda] at (v7.south east) {\(M_7\)};
+ \node[dup] (v5d1) [above left=0.5cm of v7] {\(v_5\)};
\draw[rho] (v7) -- (v5d1);
- \node[object] (v24) [below=0.6cm of v7] {$v_{24}$};
+ \node[object] (v24) [below=0.6cm of v7] {\(v_{24}\)};
\draw[parent] (v24) -- (v7);
\draw (v5) edge[bend left=30] node [attr] {\ff{t}} pic[sloped,rho]{parallel arrow={0.3,-0.15}} (v24);
- \node[dup] (v6d1) [below=1cm of v24] {$v_6$};
- \draw[ref] (v24) -- (v6d1) node [attr] {\ff{to}} node [locator] {$\rho.\rho.\ff{p}$};
- \node[dup] (v2d1) [right=1.8cm of v7] {$v_2$};
- \draw[ref] (v7) -- (v2d1) node [attr] {\ff{t}} node [locator] {$\rho.\rho.\rho.\varphi$};
+ \node[dup] (v6d1) [below=1cm of v24] {\(v_6\)};
+ \draw[ref] (v24) -- (v6d1) node [attr] {\ff{to}} node [locator] {\(\rho.\rho.\ff{p}\)};
+ \node[dup] (v2d1) [right=1.8cm of v7] {\(v_2\)};
+ \draw[ref] (v7) -- (v2d1) node [attr] {\ff{t}} node [locator] {\(\rho.\rho.\rho.\varphi\)};
- \node[object] (v15) [below=0.6cm of v2] {$v_{15}$};
- \node[dup] (v0d1) [left=1cm of v15] {$\Phi$};
+ \node[object] (v15) [below=0.6cm of v2] {\(v_{15}\)};
+ \node[dup] (v0d1) [left=1cm of v15] {\(\Phi\)};
\draw (v0d1) -- (v15) node [attr] {\ff{point}};
- \node[object] (v16) [below left=1cm of v15] {$v_{16}$};
+ \node[object] (v16) [below left=1cm of v15] {\(v_{16}\)};
\draw (v15) -- pic[sloped,rho]{parallel arrow={-0.3,-0.15}} (v16) node [attr] {\ff{x}};
- \node[object] (v17) [below right=1cm of v15] {$v_{17}$};
+ \node[object] (v17) [below right=1cm of v15] {\(v_{17}\)};
\draw (v15) -- pic[sloped,rho]{parallel arrow={0.3,-0.15}} (v17) node [attr] {\ff{y}};
- \node[atom] (v14) [below=2cm of v15] {$v_{14}$} node[lambda] at (v14.south east) {$M_{14}$};
+ \node[atom] (v14) [below=2cm of v15] {\(v_{14}\)} node[lambda] at (v14.south east) {\(M_{14}\)};
\draw (v15) -- pic[sloped,rho]{parallel arrow={0.3,-0.15}} (v14) node [attr] {\ff{distance}};
- \node[object] (v18) [left=1cm of v14] {$v_{18}$};
+ \node[object] (v18) [left=1cm of v14] {\(v_{18}\)};
\draw (v14) -- pic[sloped,rho]{parallel arrow={-0.3,-0.15}} (v18) node [attr] {\ff{to}};
- \node[object] (v10) [below right=1cm and 5cm of v15] {$v_{10}$};
- \node[dup] (v0d2) [left=1cm of v10] {$\Phi$};
+ \node[object] (v10) [below right=1cm and 5cm of v15] {\(v_{10}\)};
+ \node[dup] (v0d2) [left=1cm of v10] {\(\Phi\)};
\draw (v0d2) -- pic[sloped,rho]{parallel arrow={0.3,-0.15}} (v10) node [attr] {\ff{c}};
- \node[dup] (v1d1) [above right=0.8cm of v10] {$v_{1}$};
+ \node[dup] (v1d1) [above right=0.8cm of v10] {\(v_{1}\)};
\draw[parent] (v10) -- (v1d1);
- \node[object] (v19) [below left=1.5cm of v10] {$v_{19}$};
+ \node[object] (v19) [below left=1.5cm of v10] {\(v_{19}\)};
\draw (v10) -- pic[sloped,rho]{parallel arrow={-0.3,-0.15}} (v19) node [attr] {\ff{radius}};
\node[data] (d19) [below left=1cm of v19] {\texttt{+40}};
- \draw (v19) -- pic[sloped,rho]{parallel arrow={-0.3,-0.15}} (d19) node [attr] {$\Delta$};
- \node[object] (v11) [below right=2cm and 0.5cm of v10] {$v_{11}$};
+ \draw (v19) -- pic[sloped,rho]{parallel arrow={-0.3,-0.15}} (d19) node [attr] {\(\Delta\)};
+ \node[object] (v11) [below right=2cm and 0.5cm of v10] {\(v_{11}\)};
\draw (v10) -- pic[sloped,rho]{parallel arrow={0.3,-0.15}} (v11) node [attr] {\ff{center}};
- \node[dup] (v15d1) [left=1cm of v11] {$v_{15}$};
+ \node[dup] (v15d1) [left=1cm of v11] {\(v_{15}\)};
\draw[parent] (v11) -- (v15d1);
- \node[object] (v20) [below left=1cm of v11] {$v_{20}$};
+ \node[object] (v20) [below left=1cm of v11] {\(v_{20}\)};
\draw (v11) -- pic[sloped,rho]{parallel arrow={-0.3,-0.15}} (v20) node [attr] {\ff{x}};
\node[data] (d20) [below=1cm of v20] {\texttt{-3}};
- \draw (v20) -- pic[sloped,rho]{parallel arrow={0.3,-0.15}} (d20) node [attr] {$\Delta$};
- \node[object] (v21) [below right=1cm of v11] {$v_{21}$};
+ \draw (v20) -- pic[sloped,rho]{parallel arrow={0.3,-0.15}} (d20) node [attr] {\(\Delta\)};
+ \node[object] (v21) [below right=1cm of v11] {\(v_{21}\)};
\draw (v11) -- pic[sloped,rho]{parallel arrow={0.3,-0.15}} (v21) node [attr] {\ff{y}};
\node[data] (d21) [below=1cm of v21] {\texttt{+9}};
- \draw (v21) -- pic[sloped,rho]{parallel arrow={0.3,-0.15}} (d21) node [attr] {$\Delta$};
+ \draw (v21) -- pic[sloped,rho]{parallel arrow={0.3,-0.15}} (d21) node [attr] {\(\Delta\)};
- \node[object] (v12) [above right=0.2cm and 4cm of v10] {$v_{12}$};
- \node[dup] (v0d3) [left=1cm of v12] {$\Phi$};
+ \node[object] (v12) [above right=0.2cm and 4cm of v10] {\(v_{12}\)};
+ \node[dup] (v0d3) [left=1cm of v12] {\(\Phi\)};
\draw (v0d3) -- (v12) node [attr] {\ff{is}};
- \node[dup] (v1d2) [above left=0.8cm of v12] {$v_{1}$};
+ \node[dup] (v1d2) [above left=0.8cm of v12] {\(v_{1}\)};
\draw[parent] (v12) -- (v1d2);
- \node[dup] (v10d2) [right=1cm of v12] {$v_{10}$};
+ \node[dup] (v10d2) [right=1cm of v12] {\(v_{10}\)};
\draw[rho] (v12) -- (v10d2);
- \node[object] (v13) [below right=1cm and 0.5cm of v12] {$v_{13}$};
+ \node[object] (v13) [below right=1cm and 0.5cm of v12] {\(v_{13}\)};
\draw (v12) -- pic[sloped,rho]{parallel arrow={0.3,-0.15}} (v13) node [attr] {\ff{p}};
- \node[dup] (v15d2) [left=1cm of v13] {$v_{15}$};
+ \node[dup] (v15d2) [left=1cm of v13] {\(v_{15}\)};
\draw[parent] (v13) -- (v15d2);
- \node[object] (v22) [below left=1cm of v13] {$v_{22}$};
+ \node[object] (v22) [below left=1cm of v13] {\(v_{22}\)};
\draw (v13) -- pic[sloped,rho]{parallel arrow={-0.3,-0.15}} (v22) node [attr] {\ff{x}};
\node[data] (d22) [below=1cm of v22] {\texttt{+1}};
- \draw (v22) -- pic[sloped,rho]{parallel arrow={0.3,-0.15}} (d22) node [attr] {$\Delta$};
- \node[object] (v23) [below right=1cm of v13] {$v_{23}$};
+ \draw (v22) -- pic[sloped,rho]{parallel arrow={0.3,-0.15}} (d22) node [attr] {\(\Delta\)};
+ \node[object] (v23) [below right=1cm of v13] {\(v_{23}\)};
\draw (v13) -- pic[sloped,rho]{parallel arrow={0.3,-0.15}} (v23) node [attr] {\ff{y}};
\node[data] (d23) [below=1cm of v23] {\texttt{+7}};
- \draw (v23) -- pic[sloped,rho]{parallel arrow={0.3,-0.15}} (d23) node [attr] {$\Delta$};
+ \draw (v23) -- pic[sloped,rho]{parallel arrow={0.3,-0.15}} (d23) node [attr] {\(\Delta\)};
\node [anchor=south west] at (current bounding box.south west) {
\begin{minipage}{25em}\raggedright
- $M_{14} \to \sqrt{\begin{matrix*}[l](\mathbb{R}(\xi.\ff{to}.\ff{x}, \Delta, s)-\mathbb{R}(\rho.\ff{x}, \Delta, s))^2 + \\ + (\mathbb{R}(\xi.\ff{to}.\ff{y}, \Delta, s)-\mathbb{R}(\rho.\ff{y}, \Delta, s))^2\end{matrix*}}$ \\
- $M_5 \to \mathbb{R}(\xi.\ff{t}, \ff{lte}, s)$ \\
- $M_7 \to \mathbb{R}(\xi.\ff{t}, \ff{distance}, s)$ \\
+ \(M_{14} \to \sqrt{\begin{matrix*}[l](\mathbb{R}(\xi.\ff{to}.\ff{x}, \Delta, s)-\mathbb{R}(\rho.\ff{x}, \Delta, s))^2 + \\ + (\mathbb{R}(\xi.\ff{to}.\ff{y}, \Delta, s)-\mathbb{R}(\rho.\ff{y}, \Delta, s))^2\end{matrix*}}\) \\
+ \(M_5 \to \mathbb{R}(\xi.\ff{t}, \ff{lte}, s)\) \\
+ \(M_7 \to \mathbb{R}(\xi.\ff{t}, \ff{distance}, s)\) \\
\end{minipage}};
\end{phigure}}
-\figcap{The graph of the object \ff{is} from Eq.~\ref{eq:is}.}
+\figcap{The graph of the object \ff{is} from \cref{eq:is}.}
\label{fig:is}
\end{figure*}
diff --git a/paper/sections/syntax.tex b/paper/sections/syntax.tex
index 1e1b45f4a3..39ef7979e7 100644
--- a/paper/sections/syntax.tex
+++ b/paper/sections/syntax.tex
@@ -1,23 +1,26 @@
-Fig.~\ref{fig:bnf} demonstrates the entire syntax of \eo{} language in BNF.
-Similar to Python~\citep{lutz2013learning}, indentation in \eo{} is part of the syntax:
+The entire syntax of \eolang{} language in BNF is available on the first page of the
+\texttt{objectionary/eo} Github repository\footnote{\url{https://github.com/objectionary/eo}}.
+Similar to Python~\citep{lutz2013learning}, indentation in \eolang{} is part of the syntax:
the scope of a code block is determined by its horizontal position
in relation to other blocks, which is also known as ``off-side rule''~\citep{landin1966next}.
-There are no keywords in \eo{} but only a few special symbols
+There are no keywords in \eolang{} but only a few special symbols
denoting grammar constructs:
\ff{>} for the attributes naming,
\ff{.} for the dot notation,
- \ff{[]} for the specification of parameters of abstract objects,
+ \ff{[]} for the specification of parameters of formations,
\ff{()} for scope limitations,
\ff{!} for turning objects into constants,
\ff{:} for naming arguments,
\ff{"} (double quotes) for string literals,
\ff{@} for the \nospell{decoratee},
\ff{'} (apostroph) for explicit copying,
+ \ff{<} for object identity,
\ff{\^{}} for referring to the parent object,
+ \ff{\&{}} for referring to the home object,
and
\ff{\$} for referring to the current object.
-Attributes, which are the only identifiers that exist in \eo{}, may have
+Attributes, which are the only identifiers that exist in \eolang{}, may have
any Unicode symbols in their names, as long as they start with a small English letter
and don't contain spaces, line breaks, or special symbols mentioned above:
\ff{test-File} and
@@ -28,67 +31,6 @@
Identifiers are case-sentitive: \ff{car} and \ff{Car} are two different identifiers.
Java-notation is used for numbers and strings.
-\newcommand\sntx[1]{{\sffamily #1}}
-\begin{figure*}
-\raggedright
-\small
-\setlength\columnsep{24pt}
-\newcommand\T[1]{\sntx{#1}}
-\newcommand\V[1]{{\ttfamily `#1'}}
-\newcommand\RE[1]{{\ttfamily \textcolor{gray}{/}#1\textcolor{gray}{/}}}
-\newcommand\alt{ \textcolor{gray}{|} }
-\newcommand\grp[1]{\textcolor{gray}{(} #1 \textcolor{gray}{)}}
-\newcommand\opt[1]{\textcolor{gray}{[} #1 \textcolor{gray}{]}}
-\newcommand\few[1]{\textcolor{gray}{\{} #1 \textcolor{gray}{\}}}
-\newcommand\lex[1]{{\scshape\textcolor{darkgray}{#1}}}
-\newcommand\df{\>{\ttfamily\textcolor{gray}{::=} }}
-\begin{multicols}{2}
-\begin{tabbing}
-\hspace*{1.6cm}\= \kill
-
-\T{program} \df \opt{\T{license}} \opt{\T{metas}} \T{objects} \\
-\T{objects} \df \T{object} \lex{eol} \few{\T{object} \lex{eol}} \\
-\T{license} \df \few{\T{comment}} \lex{eol} \\
-\T{metas} \df \few{\T{meta}} \lex{eol} \\
-\T{comment} \df \V{\#} \few{\lex{any}} \lex{eol} \\
-\T{meta} \df \V{+} \T{name} \opt{\V{␣} \lex{any} \few{\lex{any}}} \lex{eol} \\
-\T{name} \df \RE{[a-z]} \few{\lex{any}} \\
-\T{object} \df \grp{ \T{foreign} \alt \T{local} } \\
-\T{foreign} \df \T{abstraction} \V{␣/} \T{name} \alt \V{?} \\
-\T{local} \df \grp{ \T{abstraction} \alt \T{application} } \T{details} \\
-\T{details} \df \opt{\T{tail}} \few{\T{vtail}} \\
-\T{tail} \df \lex{eol} \lex{tab} \few{\T{object} \lex{eol}} \lex{untab} \\
-\T{vtail} \df \lex{eol} \T{ref} \opt{\T{htail}} \opt{\T{suffix}} \opt{\T{tail}} \\
-\T{abstraction} \df \T{attributes} \opt{ \T{suffix} } \\
-\T{attributes} \df \V{[} \T{attribute} \few{\V{␣} \T{attribute}} \V{]} \\
-\T{attribute} \df \V{@} \alt \T{name} \opt{\V{...}} \\
-\T{suffix} \df \V{␣} \V{>} \V{␣} \grp{\V{@} \alt \T{name}} \opt{\V{!}} \\
-\T{ref} \df \V{.} \grp{ \T{name} \alt \V{\^{}} \alt \V{@} \alt \V{<} } \\
-\T{application} \df \T{head} \opt{\T{htail}} \\
-\T{htail} \df \T{application} \T{ref} \\
- \> \alt \V{(} \T{application} \V{)} \\
- \> \alt \T{application} \V{:} \T{name} \\
- \> \alt \T{application} \T{suffix} \\
- \> \alt \T{application} \V{␣} \T{application} \\
-\T{head} \df \opt{\V{...}} \grp{ \T{name} \opt{\V{'}} \alt \T{data} \alt \V{@} \alt \V{\$} \alt \V{\&} \\
- \> \alt \V{\^{}} \alt \V{*} \alt \T{name} \V{.} \alt \V{Q} \alt \V{QQ} } \\
-\T{data} \df \T{bytes} \alt \T{bool} \alt \T{string} \alt \T{integer} \alt \T{float} \\
-\T{bytes} \df \T{byte} \few{\V{-} \T{byte}} \alt \V{-{}-} \\
-\T{bool} \df \V{TRUE} \alt \V{FALSE} \\
-\T{byte} \df \RE{[\textbackslash{}dA-F][\textbackslash{}dA-F]} \\
-\T{string} \df \RE{"[\^{}"]*"} \\
-\T{integer} \df \RE{[+-]?\textbackslash{}d+|0x[a-f\textbackslash{}d]+} \\
-\T{float} \df \RE{[+-]?\textbackslash{}d+(\textbackslash{}.\textbackslash{}d+)?} \opt{ \RE{e(+|-)?\textbackslash{}d+} } \\
-\end{tabbing}
-\end{multicols}
-\figcap{The full syntax of \eo{} in BNF.
- \lex{eol} is a line ending that preserves the indentation of the previous line.
- \lex{tab} is a right-shift of the indentation, while \lex{untab} is a left-shift.
- \lex{any} is any symbol excluding \lex{eol}, \V{.}, and \V{␣}.
- The texts between forward slashes are Perl-style regular expressions.}
-\label{fig:bnf}
-\end{figure*}
-
\subsection{Identity, State, and Behavior}
According to~\citet{grady2007object}, an object in OOP has state, behavior, and identity:
@@ -96,16 +38,16 @@ \subsection{Identity, State, and Behavior}
the object plus the current values of each of these properties.
Behavior is how an object acts and reacts, in terms of its state changes and message passing.
Identity is that property of an object which distinguishes it from all other objects.''
-The syntax of \eo{} makes a difference between these three categories.
+The syntax of \eolang{} makes a difference between these three categories.
-This is a declaration of an abstract object \ff{book},
+This is a formation of a new object \ff{book},
which has a single \emph{identity} attribute \ff{isbn}:
\begin{ffcode}
-[isbn] > book |$\label{ln:book}$|
+[isbn] > book (*@\label{ln:book}@*)
\end{ffcode}
-To make a new object with a specific ISBN, the \ff{book}
+To make another object with a specific ISBN, the \ff{book}
has to be \emph{copied}, with the \emph{data} as an argument:
\begin{ffcode}
@@ -115,32 +57,32 @@ \subsection{Identity, State, and Behavior}
Here, \ff{b1} is a new object created.
Its only attribute is accessible as \ff{b1.isbn}.
-A similar abstract object, but with two new \emph{state} attributes, would
+A similar \emph{abstract} object, but with two new \emph{state} attributes, would
look like:
\begin{ffcode}
-[isbn] > book2 |$\label{ln:book2}$|
+[isbn] > book2 (*@\label{ln:book2}@*)
"Object Thinking" > title
- memory 0 > price |$\label{ln:book2-end}$|
+ memory 0 > price (*@\label{ln:book2-end}@*)
\end{ffcode}
The attribute \ff{title} is a constant, while the \ff{price}
represents a mutable chunk of bytes in computing memory. They both are
accessible similar to the \ff{isbn}, via \ff{book2.title}
and \ff{book2.price}. It is legal to access them in the abstract
-object, since they are bound to objects. However, accessing \ff{book2.isbn}
-will lead to an error, since the attribute \ff{isbn} is free
+object, since they are attached to objects. However, accessing \ff{book2.isbn}
+will lead to an error, since the attribute \ff{isbn} is \emph{void}
in the abstract object \ff{book2}.
A \emph{behavior} may be added to an object with a new \emph{inner}
abstract object \ff{set-price}:
\begin{ffcode}
-[isbn] > book3 |$\label{ln:book3}$|
+[isbn] > book3 (*@\label{ln:book3}@*)
"Object Thinking" > title
memory 0 > price
[p] > set-price
- ^.price.write p > @ |$\label{ln:book3-end}$|
+ ^.price.write p > @ (*@\label{ln:book3-end}@*)
\end{ffcode}
The price of the book may be changed with this one-liner:
@@ -158,21 +100,21 @@ \subsection{Indentation}
second line and the \ff{>} symbol, while two spaces will break the syntax):
{\lstset{showspaces=true}\begin{ffcode}
-# This is a vector in 2D space |$\label{ln:comment}$|
-[dx dy] > vector |$\label{ln:vector}$|
- sqrt. > length |$\label{ln:length}$|
+# This is a vector in 2D space (*@\label{ln:comment}@*)
+[dx dy] > vector (*@\label{ln:vector}@*)
+ sqrt. > length (*@\label{ln:length}@*)
plus.
dx.times dx
- dy.timex dy |$\label{ln:length-end}$| |$\label{ln:vector-end}$|
+ dy.timex dy (*@\label{ln:length-end}@*) (*@\label{ln:vector-end}@*)
\end{ffcode}
}
The code at \lref{comment} is a \emph{comment}.
-Two \emph{free attributes} \ff{dx} and \ff{dy}
+Two \emph{void attributes} \ff{dx} and \ff{dy}
are listed in square brackets at \lref{vector}.
The \emph{name} of the object goes after the \ff{>} symbol.
The code at \lref{length} defines
-a \emph{bound attribute} \ff{length}. Anywhere when an object
+an \emph{attached attribute} \ff{length}. Anywhere when an object
has to get a name, the \ff{>} symbol can be added after the object.
The declaration of the attribute \ff{length} at \lrefs{length}{length-end}
@@ -190,10 +132,10 @@ \subsection{Indentation}
inverse notation, but it will look less readable:
\begin{ffcode}
-dx.times dx |$\label{ln:dx-pow}$|
+dx.times dx (*@\label{ln:dx-pow}@*)
.plus
- dy.timex dy |$\label{ln:dx-pow-2}$|
-.sqrt > length |$\label{ln:dx-pow-3}$|
+ dy.timex dy (*@\label{ln:dx-pow-2}@*)
+.sqrt > length (*@\label{ln:dx-pow-3}@*)
\end{ffcode}
Here, \lref{dx-pow} is the application of the object \ff{dx.times} with
@@ -206,11 +148,11 @@ \subsection{Indentation}
Indentation is used for two purposes: either to define attributes
of an abstract object or to specify arguments for object application, also
known as making a \emph{copy}.
-A definition of an abstract object starts with a list of free attributes
-in square brackets on one line, followed by a list of bound attributes
+A definition of an abstract object starts with a list of void attributes
+in square brackets on one line, followed by a list of attached attributes
each in its own line. For example, this is an abstract \emph{anonymous} object
(it doesn't have a name)
-with one free attribute \ff{x} and two bound attributes \ff{succ} and \ff{prev}:
+with one void attribute \ff{x} and two attached attributes \ff{succ} and \ff{prev}:
\begin{ffcode}
[x]
@@ -223,11 +165,11 @@ \subsection{Indentation}
in a \emph{vertical} mode, where indentation will be required:
\begin{ffcode}
-[x] |$\label{ln:succ}$|
+[x] (*@\label{ln:succ}@*)
x.plus > succ
1
x.minus > prev
- 1 |$\label{ln:succ-end}$|
+ 1 (*@\label{ln:succ-end}@*)
\end{ffcode}
This abstract object can also be written in a horizontal mode,
@@ -237,9 +179,9 @@ \subsection{Indentation}
[x] (x.plus 1 > succ) (x.minus 1 > prev)
\end{ffcode}
-\subsection{\eo{} to XML}\label{sec:xml}
+\subsection{\eolang{} to XML}\label{sec:xml}
-Due the nesting nature of \eo{}, its program can be transformed
+Due to the nesting nature of \eolang{}, its program can be transformed
to an XML document. The abstract object \ff{vector} would produce
this XML tree of elements and attributes:
@@ -264,8 +206,8 @@ \subsection{\eo{} to XML}\label{sec:xml}
Each object is represented by an \ff{} XML element with a few
optional attributes, such as \ff{name} and \ff{base}. Each
-attribute is either a named reference to an object (if the attribute is bound,
-such as \ff{length}), or a name without a reference (if it is free,
+attribute is either a named reference to an object (if the attribute is attached,
+such as \ff{length}), or a name without a reference (if it is void,
such as \ff{dx} and \ff{dy}).
\subsection{Data Objects and Tuples}
@@ -279,29 +221,23 @@ \subsection{Data Objects and Tuples}
r.times 3.14 > circumference
\end{ffcode}
-This syntax would be translated to XMIR (XML based
-data format explained in Sec.~\ref{sec:xmir}):
+This syntax would be translated to XMIR (XML based data format):
\begin{ffcode}
- |$\label{ln:xml-circle}$|
+ (*@\label{ln:xml-circle}@*)
- |$\label{ln:xml-circle-r}$|
- 3.14
+ (*@\label{ln:xml-circle-r}@*)
+
+ 40-09-1E-B8-51-EB-85-1F
+
- |$\label{ln:xml-circle-end}$|
+ (*@\label{ln:xml-circle-end}@*)
\end{ffcode}
-Each object, if it is not abstract, has a ``base'' attribute in XML,
-which contains that name of an abstract object to be copied. The
-object \ff{float} is abstract, but its name
-can't be used directly in a program, similar to how \ff{r} or \ff{times}
-are used. The only way to make a copy of the abstract object \ff{float}
-is to use a numeric literal like \ff{3.14}.
-
-The abstract objects which can't be used directly and can only be
-created by the compiler through \sntx{data}---are called \emph{data}.
-The examples of some possible data are in the Tab.~\ref{tab:types}.
+Each object, if it is not a formation, has a ``base'' attribute in XML,
+which contains that name of a formation to be copied.
+The examples of some possible \emph{data objects} are in~\cref{tab:types}.
\begin{table}
\begin{tabularx}{\columnwidth}{l|X|r}
@@ -327,11 +263,11 @@ \subsection{Data Objects and Tuples}
which looks similar to object copying:
\begin{ffcode}
-* "Lucy" "Jeff" 3.14 |$\label{ln:tuple-1}$|
-* > a |$\label{ln:tuple-2a}$|
+* "Lucy" "Jeff" 3.14 (*@\label{ln:tuple-1}@*)
+* > a (*@\label{ln:tuple-2a}@*)
(* "a")
- TRUE |$\label{ln:tuple-2b}$|
-* > b |$\label{ln:tuple-3}$|
+ TRUE (*@\label{ln:tuple-2b}@*)
+* > b (*@\label{ln:tuple-3}@*)
\end{ffcode}
The code at \lref{tuple-1} makes a tuple of three elements: two strings
@@ -339,38 +275,12 @@ \subsection{Data Objects and Tuples}
tuple as its first element and \ff{TRUE} as the second item.
The code at \lref{tuple-3} is an empty tuple with the name \ff{b}.
-\subsection{Varargs}
-
-The last free attribute in an abstract object may be a \emph{vararg},
-meaning that any number or zero arguments may be provided. All of them
-will be packaged in a tuple by the compiler, for example:
-
-\begin{ffcode}
-[x...] > sum |$\label{ln:sum-def}$|
-sum 8 13 -9 |$\label{ln:sum-instance}$|
-\end{ffcode}
-
-Here, at the first line the abstract object \ff{sum} is defined
-with a free vararg attribute \ff{x}. At the second line a copy of the
-abstract object is made with three arguments. The internals of
-the \ff{sum} will see \ff{x} as an \ff{tuple} with three
-elements inside.
-
-It is possible to provide a tuple as a parameter for vararg attribute
-(both variants are semantically equivalent):
-
-\begin{ffcode}
-* 42 7 > a
-sum ...a
-sum 42 7
-\end{ffcode}
-
\subsection{Scope Brackets}
Brackets can be used to group object arguments in horizontal mode:
\begin{ffcode}
-sum (div 45 5) 10 |$\label{ln:sum}$|
+sum (div 45 5) 10 (*@\label{ln:sum}@*)
\end{ffcode}
The \ff{(div 45 5)} is a copy of the abstract object \ff{div}
@@ -393,21 +303,21 @@ \subsection{Inner Objects}
# A point on a 2D canvas
[x y] > point
[to] > distance
- length. > len |$\label{ln:vector-length}$|
+ length. > len (*@\label{ln:vector-length}@*)
vector
to.x.minus (^.x)
to.y.minus (^.y)
\end{ffcode}
-The object \ff{point} has two free attributes \ff{x} and \ff{y}
-and the attribute \ff{distance}, which is bound to an abstract
-object with one free attribute \ff{to} and one bound attribute \ff{len}.
+The object \ff{point} has two void attributes \ff{x} and \ff{y}
+and the attribute \ff{distance}, which is attached to an abstract
+object with one void attribute \ff{to} and one attached attribute \ff{len}.
The \emph{inner} abstract object \ff{distance} may only be copied
with a reference to its \emph{parent} object \ff{point}, via
a special attribute denoted by the \ff{\^{}} symbol:
\begin{ffcode}
-distance. |$\label{ln:point-copy}$|
+distance. (*@\label{ln:point-copy}@*)
point
5:x
-3:y
@@ -417,9 +327,9 @@ \subsection{Inner Objects}
\end{ffcode}
The parent object is \ff{(point 5 -3)}, while the object \ff{(point 13 3.9)}
-is the argument for the free attribute \ff{to} of the object \ff{distance}.
+is the argument for the void attribute \ff{to} of the object \ff{distance}.
Suffixes \ff{:x}, \ff{:y}, and \ff{:to} are optional and may be used
-to denote the exact name of the free attribute to be bound to the
+to denote the exact name of the void attribute to be attached to the
provided argument.
\subsection{Decorators}
@@ -427,12 +337,12 @@ \subsection{Decorators}
An object may extend another object by \emph{decorating} it:
\begin{ffcode}
-[center radius] > circle |$\label{ln:circle}$|
- center > @ |$\label{ln:circle-phi}$|
+[center radius] > circle (*@\label{ln:circle}@*)
+ center > @ (*@\label{ln:circle-phi}@*)
[p] > is-inside
lte. > @
- ^.@.distance $.p |$\label{ln:circle-phi-2}$|
- ^.radius |$\label{ln:circle-end}$|
+ ^.@.distance $.p (*@\label{ln:circle-phi-2}@*)
+ ^.radius (*@\label{ln:circle-end}@*)
\end{ffcode}
The object \ff{circle} has a special attribute \ff{@}
@@ -464,23 +374,23 @@ \subsection{Decorators}
taken from the current object (denoted by the \ff{\$} symbol).
The object \ff{circle} may be used like this, to understand whether
-the $(0,0)$ point is inside the circle at $(-3,9)$ with the radius $40$:
+the \((0,0)\) point is inside the circle at \((-3,9)\) with the radius \(40\):
\begin{ffcode}
-circle (point -3 9) 40 > c |$\label{ln:circle-c}$|
+circle (point -3 9) 40 > c (*@\label{ln:circle-c}@*)
c.is-inside (point 0 0) > i
\end{ffcode}
Here, \ff{i} will be a copy of \ff{bool} behaving like \ff{TRUE}
because \ff{lte} decorates \ff{bool}.
-It is also possible to make decoratee free, similar to other free
-attributes, specifying it in the list of free attributes in
+It is also possible to make decoratee void, similar to other void
+attributes, specifying it in the list of void attributes in
square brackets.
-\subsection{Anonymous Abstract Objects}
+\subsection{Anonymous Formations}
-An abstract object may be used as an argument of another object while
+A formation may be used as an argument of another object while
making a copy of it, for example:
\begin{ffcode}
@@ -491,14 +401,13 @@ \subsection{Anonymous Abstract Objects}
\end{ffcode}
Here the object \ff{walk} is copied with a single argument:
-the one-item tuple, which is an
-abstract object with a single free attribute \ff{f}. The \ff{walk}
-will use this abstract object, which doesn't have a name, in order
+the one-item tuple, which is a formation with a single void attribute \ff{f}. The \ff{walk}
+will use this formation, which doesn't have a name, in order
to filter out files while traversing the tree of directories. It will
-make a copy of the abstract object and then treat it as a boolean
+make a copy of the formation and then treat it as a boolean
value in order to make a decision about each file.
-The syntax may be simplified and the abstract object may be inlined
+The syntax may be simplified and the formation may be inlined
(the tuple is also inlined):
\begin{ffcode}
@@ -506,7 +415,7 @@ \subsection{Anonymous Abstract Objects}
* ([f] (f.is-dir > @))
\end{ffcode}
-An anonymous abstract object may have multiple attributes:
+An anonymous formation may have multiple attributes:
\begin{ffcode}
[x] (x.plus 1 > succ) (x.minus 1 > prev)
@@ -520,7 +429,7 @@ \subsection{Anonymous Abstract Objects}
\subsection{Constants}
-\eo{} is a declarative language with lazy evaluations. This means
+\eolang{} is a declarative language with lazy evaluations. This means
that this code would read the input stream two times:
\begin{ffcode}
@@ -609,14 +518,14 @@ \subsection{Metas and License}
+package org.example
+alias org.eolang.io.stdout
-[args...] > app
+[args] > app
stdout > @
"Hello, world!\n"
\end{ffcode}
\subsection{Atoms}
-Some objects in \eo{} programs may need to be platform specific
+Some objects in \eolang{} programs may need to be platform specific
and can't be composed from other existing objects---they are called
\emph{atoms}.
For example, the object \ff{app} uses the object \ff{stdout},
@@ -627,11 +536,11 @@ \subsection{Atoms}
+rt jvm org.eolang:eo-runtime:0.7.0
+rt ruby eolang:0.1.0
-[text] > stdout /bool |$\label{ln:stdout}$|
+[text] > stdout /bool (*@\label{ln:stdout}@*)
\end{ffcode}
The \ff{/bool} suffix informs the compiler that this object must
-not be compiled from \eo{} to the target language. The object
+not be compiled from \eolang{} to the target language. The object
with this suffix already exists in the target language and most
probably could be found in the library specified by the \ff{rt}
meta. The exact library to import has to be selected by the compiler.
@@ -642,7 +551,7 @@ \subsection{Atoms}
object, which \ff{stdout} decorates. The name may be replaced by
a question mark, if uncertain about the object being decorated.
-Atoms in \eo{} are similar to ``native'' methods in Java and ``\nospell{extern}'' methods in C\#: this mechanism is also known as foreign function interface (FFI).
+Atoms in \eolang{} are similar to ``native'' methods in Java and ``\nospell{extern}'' methods in C\#: this mechanism is also known as foreign function interface (FFI).
\subsection{Home Object}
@@ -651,11 +560,11 @@ \subsection{Home Object}
how object \ff{tuple.map} is implemented in Objectionary:
\begin{ffcode}
-[] > list |$\label{ln:list-parent}$|
- [f] > mapi /list |$\label{ln:list-map}$|
+[] > list (*@\label{ln:list-parent}@*)
+ [f] > mapi /list (*@\label{ln:list-map}@*)
[f] > map
^.mapi > @
- [x i] |$\label{ln:map-inner}$|
+ [x i] (*@\label{ln:map-inner}@*)
&.f x > @
\end{ffcode}
diff --git a/paper/sections/xmir.tex b/paper/sections/xmir.tex
index 3b0d7e85f4..e74e4dba39 100644
--- a/paper/sections/xmir.tex
+++ b/paper/sections/xmir.tex
@@ -1,7 +1,7 @@
-Consider this sample \eo{} snippet:
+Consider this sample \eolang{} snippet:
\begin{ffcode}
-[x y...] > app
+[x y] > app
42 > n!
[t] > read
minus.
@@ -14,16 +14,16 @@
\begin{ffcode}
-
+
42 |$\label{ln:xml-data}$|
+ line="2" name="n">42 (*@\label{ln:xml-data}@*)
- |$\label{ln:xml-minus}$|
- |$\label{ln:method-start}$|
- |$\label{ln:method-end}$|
+ (*@\label{ln:xml-minus}@*)
+ (*@\label{ln:method-start}@*)
+ (*@\label{ln:method-end}@*)
- |$\label{ln:xml-minus-end}$|
+ (*@\label{ln:xml-minus-end}@*)
\end{ffcode}
@@ -46,12 +46,12 @@
goes away):
\begin{ffcode}
- |$\label{ln:new-minus}$|
- |$\label{ln:xml-neg}$|
+ (*@\label{ln:new-minus}@*)
+ (*@\label{ln:xml-neg}@*)
- |$\label{ln:xml-neg-end}$|
+ (*@\label{ln:xml-neg-end}@*)
- |$\label{ln:new-minus-end}$|
+ (*@\label{ln:new-minus-end}@*)
\end{ffcode}
The semantics of the element \ff{.minus} at~\lref{xml-minus}
@@ -59,13 +59,11 @@
notation for child-parent relationships. The XML element at~\lrefs{xml-neg}{xml-neg-end}
means \ff{neg. n} or \ff{n.neg}. The
leading dot at the attribute \ff{base} means that the first
-child of this XML element is the \eo{} parent of it.
+child of this XML element is the \eolang{} parent of it.
Similarly, the XML element at ~\lrefs{new-minus}{new-minus-end}
means \ff{minus. (neg. n) t}, or \ff{(neg. n).minus t}, or \ff{n.neg.minus t}.
The attribute \ff{data} is used when the object is data. In this
case, the data itself is in the text of the object, as in~\lref{xml-data}.
-The attribute \ff{vararg} denotes a vararg attribute.
-
The attribute \ff{const} denotes a constant.