diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..3c7bc69 --- /dev/null +++ b/.gitignore @@ -0,0 +1,16 @@ +.DS_Store +_minted-* +*.pdf +*.bbl +*.bcf +*.blg +*.fdb_latexmk +*.fls +*.log +*.run.xml +*.aux +*.pyg +*.out +*.synctex.gz +*.zip +package/ \ No newline at end of file diff --git a/.latexmkrc b/.latexmkrc new file mode 100644 index 0000000..d7e9c91 --- /dev/null +++ b/.latexmkrc @@ -0,0 +1,2 @@ +$pdflatex = 'pdflatex %O --shell-escape %S'; +$success_cmd = 'texqc && texsc'; \ No newline at end of file diff --git a/.texsc b/.texsc new file mode 100644 index 0000000..d60cbbb --- /dev/null +++ b/.texsc @@ -0,0 +1,16 @@ +--pws=aspell.en.pws +--ignore=nospell +--ignore=equation* +--ignore=ffcode +--ignore=setminted +--ignore=opt,grp,T,V,few,RE +--ignore=newminted:opp +--ignore=newtcbox:pp +--ignore=settopmatter +--ignore=CJK +--ignore=lref:p,lrefs:pp +--ignore=tikzstyle,tikzpicture,usetikzlibrary,ingraph +--ignore=tikz:op +--ignore=textcolor:pp +--ignore=newmdenv:op +--ignore=f,code,nospell,citet,citep diff --git a/Makefile b/Makefile new file mode 100644 index 0000000..89731ac --- /dev/null +++ b/Makefile @@ -0,0 +1,52 @@ +# The MIT License (MIT) +# +# Copyright (c) 2020-2022 Yegor Bugayenko +# +# Permission is hereby granted, free of charge, to any person obtaining a copy +# of this software and associated documentation files (the "Software"), to deal +# in the Software without restriction, including without limitation the rights +# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell +# copies of the Software, and to permit persons to whom the Software is +# furnished to do so, subject to the following conditions: +# +# The above copyright notice and this permission notice shall be included +# in all copies or substantial portions of the Software. +# +# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +# FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE +# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, +# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE +# SOFTWARE. + +.SHELLFLAGS = -e -x -c +.ONESHELL: + +TLROOT=$$(kpsewhich -var-value TEXMFDIST) +PACKAGES=ffcode to-be-determined href-ul +REPO=yegor256/reducing-programs-to-objects + +zip: *.tex + rm -rf package + mkdir package + cd package + cp ../paper.tex . + cp ../main.bib . + for p in $(PACKAGES); do cp $(TLROOT)/tex/latex/$${p}/$${p}.sty .; done + version=$$(curl --silent -H "Accept: application/vnd.github.v3+json" https://api.github.com/repos/$(REPO)/releases/latest | jq -r '.tag_name') + echo "Version is: $${version}" + gsed -i "s|0\.0\.0|$${version}|" paper.tex + gsed -i "s|REPOSITORY|$(REPO)|" paper.tex + pdflatex -shell-escape -halt-on-error paper.tex > /dev/null + bibtex paper + pdflatex -halt-on-error paper.tex > /dev/null + pdflatex -halt-on-error paper.tex > /dev/null + rm -rf *.aux *.bcf *.blg *.fdb_latexmk *.fls *.log *.run.xml *.out *.exc + zip -x paper.pdf -r paper-$${version}.zip * + mv paper-$${version}.zip .. + cd .. + +clean: + git clean -dfX + diff --git a/README.md b/README.md new file mode 100644 index 0000000..259dff8 --- /dev/null +++ b/README.md @@ -0,0 +1,22 @@ + + +[![make](https://github.com/objectionary/eo/actions/workflows/latexmk.yml/badge.svg)](https://github.com/objectionary/eo/actions/workflows/latexmk.yml) + +This is a more or less formal description of EOLANG and 𝜑-calculus. + +To build it, just run: + +```bash +$ make +``` + +You need to have +[`aspell`](http://aspell.net/), +LaTeX, +[`biblint`](https://github.com/Kingsford-Group/biblint), +[`texsc`](https://rubygems.org/gems/texsc), +and +[`texqc`](https://rubygems.org/gems/texqc) +installed. + +Once compiled and packaged, upload zip archive to [arXiv](https://arxiv.org/abs/2111.13384). diff --git a/aspell.en.pws b/aspell.en.pws new file mode 100644 index 0000000..f93ce20 --- /dev/null +++ b/aspell.en.pws @@ -0,0 +1,3 @@ +personal_ws-1.1 en 741 utf-8 +Yegor +Bugayenko diff --git a/main.bib b/main.bib new file mode 100644 index 0000000..1997877 --- /dev/null +++ b/main.bib @@ -0,0 +1,52 @@ +@misc{bugayenko2021eolang, + title={EOLANG and phi-calculus}, + author={Yegor Bugayenko}, + year={2021}, + eprint={2111.13384}, + archivePrefix={arXiv}, + primaryClass={cs.PL} +} + +@article{williams1985restructuring, + title={Restructuring Pascal Programs Containing Goto Statements}, + author={Williams, M. Howard and Chen, G}, + journal={The Computer Journal}, + volume={28}, + number={2}, + pages={134--137}, + year={1985}, + publisher={Oxford University Press} +} + +@article{pan1996formal, + title={A Formal Basis for Removing Goto Statements}, + author={Pan, Si and Dromey, R. Geoff}, + journal={The Computer Journal}, + volume={39}, + number={3}, + pages={203--214}, + year={1996}, + publisher={Oxford University Press} +} + +@inproceedings{erosa1994taming, + title={Taming Control Flow: A structured approach to eliminating goto statements}, + author={Erosa, Ana M and Hendren, Laurie J}, + booktitle={Proceedings of 1994 IEEE International Conference on Computer Languages (ICCL'94)}, + pages={229--240}, + publisher={IEEE}, + address={USA}, + year={1994}, + organization={IEEE} +} + +@inproceedings{ceccato2008goto, + title={Goto Elimination Strategies in the Migration of Legacy Code to Java}, + author={Ceccato, Mariano and Tonella, Paolo and Matteotti, Cristina}, + booktitle={2008 12th European Conference on Software Maintenance and Reengineering}, + publisher={IEEE}, + address={USA}, + pages={53--62}, + year={2008}, + organization={IEEE} +} \ No newline at end of file diff --git a/paper.tex b/paper.tex new file mode 100644 index 0000000..b4512b5 --- /dev/null +++ b/paper.tex @@ -0,0 +1,1045 @@ +\documentclass[sigplan,nonacm,11pt]{acmart} +\usepackage[utf8]{inputenc} +\usepackage[nocn]{ffcode} +\usepackage{tikz} +\usepackage{to-be-determined} +\setlength\footskip{16pt} + +\title{Reducing Programs to Objects} +\subtitle{ + Ver: + \texorpdfstring{ + \href{https://github.com/REPOSITORY/releases/tag/0.0.0} + {\ff{0.0.0}} + }{0.0.0} +} +\author{Yegor Bugayenko} +% \affiliation{Huawei\country{Russia}\city{Moscow}} +\email{yegor256@gmail.com} + +\begin{abstract} +C++, Java, C\#, Python, Ruby, JavaScript are the most powerful object-oriented programming languages, if language power would be defined as the number of \emph{features} available for a programmer. EO, on the other hand, is an object-oriented programming language with a reduced set of features: it has nothing by objects and mechanisms of their composition and decoration. We are trying to answer the following research question: ``Which known features are possible to implement using only objects?'' +\end{abstract} + +\begin{document} + +\maketitle + +\section{Features} + +To answer our research question we selected most complex features and demonstrated how each of them may be represented in EO~\citep{bugayenko2021eolang} objects: + +\begin{itemize} + \item Non-conditional jumps + (Sec.~\ref{sec:goto}), + \item Data and code pointers + (Sec.~\ref{sec:pointers}), + \item Procedures + (Sec.~\ref{sec:procedures}), + \item Classes + (Sec.~\ref{sec:classes}), + \item Exceptions + (Sec.~\ref{sec:exceptions}), + \item Anonymous functions + (Sec.~\ref{sec:blocks}), + \item Generators + (Sec.~\ref{sec:generators}), + \item Types and casting + (Sec.~\ref{sec:types}), + \item Reflection + (Sec.~\ref{sec:reflection}), + \item Static methods + (Sec.~\ref{sec:static}), + \item Inheritance + (Sec.~\ref{sec:inheritance}), + \item Method overloading + (Sec.~\ref{sec:overloading}), + \item Java generics + (Sec.~\ref{sec:generics}), + \item C++ templates + (Sec.~\ref{sec:templates}), + \item Mixins + (Sec.~\ref{sec:mixins}), + \item Java annotations + (Sec.~\ref{sec:annotations}). +\end{itemize} + +Other features are more trivial, that's why they are not presented in this paper, such as operators, loops, variables, code blocks, constants, branching, and so on. + +\subsection{Goto} +\label{sec:goto} + +Goto is a one-way imperative transfer of control to another line of code. There are only two possible cases of goto jumps: forward and backward. + +\subsubsection{Backward Jump} + +This is a ``backward'' jump example in C language: + +\begin{ffcode} +#include "stdio.h" +void f() { + int i = 1; + again: + i++; + if (i < 10) goto again; + printf("Finished!"); +} +\end{ffcode} + +It can be mapped to the following EO code: + +\begin{ffcode} +[] > f + memory > i + seq > @ + i.write 1 + Q.org.eolang.gray.goto + [g] + seq > @ + i.write (i.add 1) + if. + i.less 10 + g.backward + TRUE + Q.org.eolang.io.stdout "Finished!" +\end{ffcode} + +Here, the one-argument abstract atom \ff{goto} is being copied with a one-argument abstract anonymous object, which is the sequence of objects doing the increment of \ff{i} and then the comparison of it with the number ten. If the condition is true, \ff{g.backward} is called, which leads to a backward jump and re-iteration of \ff{goto}. + +\subsubsection{Forward Jump} + +This is an example of a ``forward'' jump in C language: + +\begin{ffcode} +int f(int x) { + int r = 0; + if (x == 0) goto exit; + r = 42 / x; + exit: + return r; +} +\end{ffcode} + +It can be mapped to the following EO code: + +\begin{ffcode} +[x] > f + memory > r + seq > @ + r.write 0 + Q.org.eolang.gray.goto + [g] + seq > @ + if. + x.eq 0 + g.forward + TRUE + r.write (42.div x) + r +\end{ffcode} + +Here, the same abstract atom \ff{goto} is copied with an abstract one-argument object, which is a sequence of objects. When the condition is true, a forward jump is performed by \ff{g.forward} atom. + +Similar way, the atom \ff{goto} may be used to simulate other conditional jump statements, like \ff{break}, \ff{continue}, or \ff{return} in the middle of a function body (see Sec.~\ref{sec:procedures}). + +\subsubsection{Complex Case} + +This is a more complex case of using \ff{goto} in C: + +\begin{ffcode} +#include "stdio.h" +void f(int a, int b) { + goto start; +back: + printf("A"); +start: + if (a > b) goto back; + printf("B"); +} +\end{ffcode} + +In order to translate this code to EO it has to be refactored as Fig.~\ref{fig:goto} demonstrates. The function \ff{f()} is copied twice and each copy has its own execution flow implemented. + +\begin{figure} +\includegraphics[width=0.9\columnwidth]{goto-pic} +\caption{The function \ff{f} with a few \ff{goto} statements inside is translated to two functions, reducing the complexity of the code at the cost of introducing duplication.} +\label{fig:goto} +\end{figure} + +\begin{ffcode} +#include "stdio.h" +void f(int a, int b) { f1(a, b); } +void f1(int a, int b) { + if (a > b) f2(a, b); + printf("B"); +} +void f2(int a, int b) { +back: + printf("A"); + if (a > b) goto back; + printf("B"); +} +\end{ffcode} + +Then, the translation to EO is trivial, with the use of the \ff{goto} object. + +In more complex cases a program may first be restructured to replace \ff{goto} statements with loops and branching, as suggested by~\citet{williams1985restructuring,pan1996formal,erosa1994taming,ceccato2008goto}. + +\subsubsection{Multiple Returns} + +Some programming languages allow a function to exit at an arbitrary place, not only at the end, using \ff{return} statements, for example: + +\begin{ffcode} +void abs(int x) { + if (x > 0) { + return x; + } + return -1 * x; +} +\end{ffcode} + +This can be mapped to the following EO code using \ff{goto} object: + +\begin{ffcode} +[x] > abs + Q.org.eolang.gray.goto > @ + [g] + seq > @ + if. + x.greater 0 + g.forward x + TRUE + g.forward + -1.mul x +\end{ffcode} + +The dataization of \ff{g.forward} will exit the \ff{goto} object wrapping the entire code in the ``function'' \ff{abs}. + +\subsection{Pointers} +\label{sec:pointers} + +A pointer is an object in many programming languages that stores a memory address. Pointers may point to data memory and to program memory. + +\subsubsection{Pointers to Data} + +This is an example of C code, where the pointer \ff{p} is first incremented by seven times \ff{sizeof(book)} (which is equal to 108) and then de-referenced to become a struct \ff{book} mapped to memory. Then, the \ff{title} part of the struct is filled with a string and the \ff{price} part is returned as a result of the function \ff{f}: + +\begin{ffcode} +#include "string.h" +struct book { + char title[100]; + long long price; +}; +int f(struct book* p) { + struct book b = *(p + 7); + strcpy(b.title, "Object Thinking"); + return b.price; +} +\end{ffcode} + +This code can be mapped to the following EO code: + +\begin{ffcode} +[ptr] > book + ptr.block > title + 100 + [b] (b.as-string > @) + ptr.block > price + 8 + [b] (b.as-int > @) +Q.org.eolang.gray.heap.pointer > p1 + 0x1A76EC09 + 108 +[p] > f + seq > @ + book (p.add 7) > b + b.title.write "Object Thinking" + b.price +\end{ffcode} + +Here, \ff{p1} is an object that can be used as an argument of \ff{f}. It is a copy of an abstract object \ff{heap.pointer}, which expects two: 1)~an absolute address in memory, and 2)~the size of the memory block it points to, in bytes. Its attribute \ff{block} expects two attributes: 1) the number of bytes in the heap, and 2)~an abstract object that can encapsulate \ff{bytes} which were just read from memory. + +The object \ff{heap} is an abstraction of a random access memory. + +\subsubsection{Pointers to Code} + +A pointer may not only refer to data in the heap, but also to executable code in memory (there is no difference between ``program'' and ``data'' memories both in x86 and ARM architectures). This is an example of C program, which calls a function referenced by a function pointer, providing two integer arguments to it: + +\begin{ffcode} +int foo(int x, int y) { + return x + y; +} +int f() { + int (*p)(int, int); + p = &foo; + return (*p) (7, 42); +} +\end{ffcode} + +This code can be mapped to the following EO code: + +\begin{ffcode} +[x y] > foo + x.add y > @ +[] > f + Q.org.eolang.gray.cage > p + seq > @ + p.write + [x y] + foo x y > @ + p 7 42 +\end{ffcode} + +Important to notice that the following code is not possible to represent in EO: + +\begin{ffcode} +int f() { + int (*p)(int); + p = (int(*)(int)) 0x761AFE65; + return (*p) (42); +} +\end{ffcode} + +Here, the pointer refers to an arbitrary address in program memory, where some executable code is supposed to be located. + +\subsubsection{Variables in Stack} + +This C function, which returns seven (tested with GCC), assumes that variables are placed in stack sequentially and uses pointer de-referencing to access them: + +\begin{ffcode} +int f() { + long long a = 42; + long long b = 7; + return *(&a - 1); +} +\end{ffcode} + +This code can be mapped to the following EO code: + +\begin{ffcode} +[p] > long64 + p.block > @ + 8 + [b] (b.as-int > @) +[p] > f + seq > @ + Q.org.eolang.gray.heap.malloc 16 > stack + long64 (stack.pointer 0 8) > b + b.write 7 + long64 (stack.pointer 8 8) > a + a.write 42 + long64 (a.p.sub 1) > ret! + h.free stack + ret +\end{ffcode} + +Here, the atom \ff{malloc} allocates a segment of bytes in the \ff{heap}. Later, the atom \ff{free} releases it. The attribute \ff{ret} is made constant in order to avoid its recalculation after it's ``returned'' (this mechanism is explained in Sec.~\ref{sec:destructors} where destructors are discussed). + +\subsection{Procedures} +\label{sec:procedures} + +A subroutine is a sequence of program instructions that performs a specific task, packaged as a unit. In different programming languages, a subroutine may be called a routine, subprogram, function, method, or procedure. In this PHP example, a function \ff{max} is defined: + +\begin{ffcode} +function max($a, $b) { + if ($a > $b) return $a; + return $b; +} +\end{ffcode} + +It can be mapped to the following EO code: + +\begin{ffcode} +[a b] > max + goto > @ + [g] + seq > @ + if. + a.greater b + g.forward a + TRUE + b +\end{ffcode} + +This example also demonstrates how \ff{goto} object can be used to simulate the behavior of the \ff{return} statement from within the body of a method. + +\subsection{Classes} +\label{sec:classes} + +A class is an extensible program-code-template for creating objects, providing initial values for state (member variables) and implementations of behavior (member functions or methods). The following program contains a Ruby class with a single constructor, two methods, and one mutable member variable: + +\begin{ffcode} +class Book + def initialize(i) + @id = id + puts "New book!" + end + def path + "/tmp/${@id}.txt" + end + def move(i) + @id = i + end +end +\end{ffcode} + +It can be mapped to the following EO code, where a class becomes a factory of objects: + +\begin{ffcode} ++import org.eolang.gray.cage ++import org.eolang.txt.sprintf + +[] > book + [i] > new + cage > id + seq > @ + id.write i + [] + [] > path + sprintf > @ + "/tmp/%s.txt" + id + [i] > move + id.write i > @ +\end{ffcode} + +Here, the constructor is represented by the object \ff{new}, which initializes the ``gray'' object \ff{cage} with the incoming parameter \ff{i} and then makes a new anonymous object with two attributes \ff{path} and \ff{move}. The making an ``instance'' of a book would look like this: + +\begin{ffcode} +book.new 42 > b +b.move 7 +b.path +\end{ffcode} + +\subsection{Destructors} +\label{sec:destructors} + +In C++ and some other languages, a destructor is a method that is called for a class object when that object passes out of scope or is explicitly deleted. The following code will print both \ff{Alive} and \ff{Dead} texts: + +\begin{ffcode} +#include +class Foo { +public: + Foo() { std::cout << "Alive"; } + ~Foo() { std::cout << "Dead"; }; +}; +int main() { + Foo f = Foo(); +} +\end{ffcode} + +It may be translated to EO as such: + +\begin{ffcode} ++import org.eolang.io.stdout + +[] > Foo + [] > new + seq > @ + stdout "Alive" > @ + [] + [] > destructor + stdout "Dead" > @ +[] > main + seq > @ + Foo.new > f + f.destructor +\end{ffcode} + +There is no garbage collection in EO, that's why a destructor must be explicitly ``called'' when an object passes out of scope or is deleted. + +\subsection{Exceptions} +\label{sec:exceptions} + +Exception handling is the process of responding to the occurrence of exceptions---anomalous or exceptional conditions requiring special processing---during the execution of a program provided. This C++ program utilizes exception handling to avoid segmentation fault due to null pointer de-referencing: + +\begin{ffcode} +#include +class Book { public: int price(); }; +int price(Book* b) { + if (b == NULL) throw "NPE!"; + return (*b).price() * 1.1; +} +void print(Book* b) { + try { + std::cout << "The price: " << price(b); + } catch (char const* e) { + std::cout << "Error: " << e; + } +} +\end{ffcode} + +This mechanism may be implemented in EO: + +\begin{ffcode} +[] > Book + [] > price /int +[b throw] > price + if. > @ + b.eq 0 + throw "error!" + (Book b).price.mul 1.1 +[b] > print + Q.org.eolang.gray.try > @ + [t] + seq > @ + stdout "The price: " + stdout (price b t).as-string + [e] + seq > @ + stdout "Error: " + stdout e + TRUE +\end{ffcode} + +Here, the object \ff{try} expects three arguments: 1)~an abstract object to be dataized, and 2)~an abstract object to be copied with one argument, in case dataization fails, and 3)~an object to be dataized anyway (similar to Java \ff{finaly} block). + +The object \ff{ff} expects two arguments instead of one, as in C++ example. The second argument is the object \ff{throw}, which if copied and dataized, causes the termination of dataization and a non-conditional jump to the ``catch'' object of the \ff{try}. The mechanism is similar to ``checked'' exceptions in Java, where a method's signature must declare all types of exceptions the method may throw. + +\subsubsection{Many Exception Types} + +A Java method may throw a number of either checked or unchecked exceptions, for example: + +\begin{ffcode} +void f(int x) throws IOException { + if (x == 0) { + throw new IOException(); + } + throw new RuntimeException(); +} +\end{ffcode} + +This would be represented in EO as such: + +\begin{ffcode} +[x io-throw rt-throw] > f + seq > @ + if. + x.eq 0 + io-throw + TRUE + rt-throw +\end{ffcode} + +To catch both exceptions the object \ff{f} would be used like this: + +\begin{ffcode} +try + [rt-throw] + try > @ + [io-throw] + f 5 io-throw rt-throw > @ + [e1] + stdout e1.message > @ + TRUE + [e2] + stdout e2.message > @ + TRUE +\end{ffcode} + +\subsection{Anonymous Functions} +\label{sec:blocks} + +Anonymous functions that can be passed into methods as arguments. For example, in this Ruby code a ``block'' (a name Ruby uses for anonymous functions) is passed: + +\begin{ffcode} +def scan(lines) + lines.each do |t| + if t.starts_with? '#' yield t + end +end +scan(array) { |x| puts x } +\end{ffcode} + +This mechanism may be implemented in EO: + +\begin{ffcode} ++import org.eolang.io.stdout + +[lines b] > scan + lines.each > @ + [t] + if. > @ + t.starts '#' + b t + TRUE +scan + array + [x] + stdout x > @ +\end{ffcode} + +Here, the anonymous function passed to the object \ff{scan} as an argument \ff{b}. The ``call'' of this function is the dataization of its copy, performed by the \ff{if} atom. + +\subsection{Generators} +\label{sec:generators} + +A generator is a routine that can be used to control the iteration behaviour of a loop. For example, this PHP program will print first ten Fibonacci numbers: + +\begin{ffcode} +function fibonacci(int $limit):generator { + yield $a = $b = $i = 1; + while (++$i < $limit) { + $b = $a + $b; + yield $b - $a; + $a = $b; + } +} +foreach (fibonacci(10) as $n) { + echo "$n\n"; +} +\end{ffcode} + +This mechanism may be implemented in EO: + +\begin{ffcode} ++import org.eolang.io.stdout ++import org.eolang.txt.sprintf + +[limit f] > fibonacci + memory > a + memory > b + memory > i + seq > @ + a.write 1 + b.write 1 + f 1 + while. + seq (i.write (i.add 1)) (i.less limit) + [idx] + seq > @ + b.write a.add b + f (b.sub a) + a.write b +fibonacci + 10 + [n] + stdout > @ + sprintf "%d\n" n +\end{ffcode} + +Here, the generator is turned into an object \ff{fibonacci} with an extra parameter \ff{f}, which is specified with an abstract object argument, which prints what's given as \ff{n}. + +\subsection{Types and Type Casting} +\label{sec:types} + +A type system is a logical system comprising a set of rules that assigns a property called a type to the various constructs of a computer program, such as variables, expressions, functions or modules. The main purpose of a type system is to reduce possibilities for bugs in computer programs by defining interfaces between different parts of a computer program, and then checking that the parts have been connected in a consistent way. In this example, a Java method \ff{add} expects an argument of type \ff{Book} and compilation would fail if another type is provided: + +\begin{ffcode} +class Cart { + private int total; + void add(Book b) { + this.total += b.price(); + } +} +\end{ffcode} + +The restrictions enforced by Java type system through types \ff{Cart} and \ff{Book} may be represented in EO by means of decorators, for example: + +\begin{ffcode} +[] > original-cart + memory > total + [b] > add + total.write (total.add b.price) +[] > Cart + original-cart > @ + [b] > add + if. + b.&.subtype-of "Book" + @.add b + [] + msg > "Type mismatch, Book expected" +\end{ffcode} + +Here, it is expected that the parameter \ff{b} is defined in a ``class,'' which has \ff{subtype-of} attribute, which may also be provided by a decorator (a simplified example): + +\begin{ffcode} +[] > original-book + memory > price +[] > Book + original-book > @ + [t] > subtype-of + t.eq "Book" > @ + [] > price + @.price > @ +\end{ffcode} + +This decoration may be simplified through a ``fluent'' supplementary object: + +\begin{ffcode} ++import org.eolang.gray.type + +type "Cart" > cart-type +.super-types "Object" "Printable" +.method "add" "Book" +cart-type original-cart > cart +\end{ffcode} + +Here, the \ff{type} object implements all necessary restrictions Java type system may provide for the type \ff{Cart} and its methods. + +Type casting, which is a mechanism of changing an expression from one data type to another, may also be implemented through same decorators. + +\subsection{Reflection} +\label{sec:reflection} + +Reflection is the ability of a process to examine, introspect, and modify its own structure and behavior. In the following Python example the method \ff{hello} of an instance of class \ff{Foo} is not called directly on the object, but is first retrieved through reflection functions \ff{globals} and \ff{getattr}, and then executed: + +\begin{ffcode} +def Foo(): + def hello(self, name): + print("Hello, %s!" % name) +obj = globals()["Foo"]() +getattr(obj, "hello")("Jeff") +\end{ffcode} + +It may be implemented in EO just by encapsulating additional meta information in classes explained in Sec.~\ref{sec:classes}. + +\subsubsection{Monkey Patching} + +Monkey patching is making changes to a module or a class while the program is running. This JavaScript program adds a new method \ff{print} to the object \ff{b} after the object has already been instantiated: + +\begin{ffcode} +function Book(t) { this.title = t; } +var b = new Book("Object Thinking"); +b.print = function() { + console.log(this.title); +} +b.print(); +\end{ffcode} + +This program may be translated to EO, assuming that \ff{b} is being held by an attribute of a larger object, for example \ff{app}: + +\begin{ffcode} +[] > app + Q.org.eolang.gray.cage > b + b' > copy + seq > @ + b.write + [] > Book + [t] > new + memory > title + seq > @ + title.write t + [] + copy.< + b.write + [] > Book + [t] > new + seq > @ + [] + copy > @ + [] > print + stdout (^.title) + b.print +\end{ffcode} + +Here, the modification to the object \ff{Book} is happening through making a copy of it, creating a decorator, and then storing it to where the original object was located. + +\subsection{Static Methods} +\label{sec:static} + +A static method (or static function) is a method defined as a member of an object but is accessible directly from an API object's constructor, rather than from an object instance created via the constructor. For example, this C\# class consists of a single static method: + +\begin{ffcode} +class Utils { + public static int max(int a, int b) { + if (a > b) return a; + return b; + } +} +\end{ffcode} + +It may be converted to the following EO code, since a static method is nothing else but a ``global'' function: + +\begin{ffcode} +[a b] > Utils-max + if. > @ + a.greater b + a + b +\end{ffcode} + +\subsection{Inheritance} +\label{sec:inheritance} + +Inheritance is the mechanism of basing a class upon another class retaining similar implementation. In this Java code class \ff{Book} inherits all methods and non-private attributes from class \ff{Item}: + +\begin{ffcode} +class Item { + private int p; + int price() { return p; } +} +class Book extends Item { + int tax() { return price() * 0.1; } +} +\end{ffcode} + +It may be represented in EO like this: + +\begin{ffcode} +[] > item + memory > p + [] > price + p > @ +[] > book + item > i + [] > tax + i.price.mul 0.1 >@ +\end{ffcode} + +Here, composition is used instead of inheritance. + +\subsubsection{Prototype-Based Inheritance} + +Prototype-based programming uses generalized objects, which can then be cloned and extended. For example, this JavaScript program defines two objects, where \ff{Item} is the parent object and \ff{Book} is the child that inherits the parent through its prototype: + +\begin{ffcode} +function Item(p) { this.price = p; } +function Book(p) { + Item.call(this, p); + this.tax = function () { + return this.price * 0.1; + } +} +var t = new Book(42).tax(); +console.log(t); // prints "4.2" +\end{ffcode} + +This mechanism of prototype-based inheritance may be translated to the following EO code, using the mechanism of decoration: + +\begin{ffcode} +[] > Item + [p] > new + memory > price + seq > @ + price.write p + [] +[] > Book + [p] > new + [] + Item p > @ + [] > tax + mul. > @ + ^.price + 0.1 +stdout + as-string. + tax. + Book.new 42 +\end{ffcode} + +\subsubsection{Multiple Inheritance} + +Multiple inheritance is a feature of some object-oriented computer programming languages in which an object or class can inherit features from more than one parent object or parent class. In this C++ example, +the class \ff{Jack} has both \ff{bark} and \ff{listen} methods, inherited from \ff{Dog} and \ff{Friend} respectively: + +\begin{ffcode} +#include +class Dog { + virtual void bark() { + std::cout << "Bark!"; + } +}; +class Friend { + virtual void listen(); +}; +class Jack: Dog, Friend { + void listen() override { + Dog::bark(); + std::cout << "Listen!"; + } +}; +\end{ffcode} + +It may be represented in EO like this: + +\begin{ffcode} ++import org.eolang.io.stdout + +[] > dog + [] > bark + stdout "Bark!" > @ +[] > jack + dog > d + friend > f + [] > listen + seq > @ + d.bark + stdout "listen!" +\end{ffcode} + +Here, inherited methods are explicitly listen as attributes in the object \ff{jack}. This is very close to what would happen in the virtual table of a class \ff{Jack} in C++. The EO object \ff{jack} just makes it explicit. + +\subsection{Method Overloading} +\label{sec:overloading} + +Method overloading is the ability to create multiple functions of the same name with different implementations. Calls to an overloaded function will run a specific implementation of that function appropriate to the context of the call, allowing one function call to perform different tasks depending on context. In this Kotlin program two functions are defined with the same name, while only one of them is called with an integer argument: + +\begin{ffcode} +fun foo(a: Int) {} +fun foo(a: Double) {} +foo(42) +\end{ffcode} + +It may be represented in EO like this: + +\begin{ffcode} +[args...] > foo + (args.get 0) > a0 + if. + a0.&.subtype-of "Int" + first-foo a0 + second-foo a0 +foo 42 +\end{ffcode} + +This code expects arguments of \ff{foo} to be equipped with the type system suggested in Sec.~\ref{sec:types}. The attribute \ff{subtype-of} will help dispatching the call to the right objects. + +\subsection{Java Generics} +\label{sec:generics} + +Generics extend Java's type system to allow a type or method to operate on objects of various types while providing compile-time type safety. For example, this Java class expects another class to be specified as \ff{T} before usage: + +\begin{ffcode} +class Cart { + private int total; + void add(T i) { + total += i.price(); + } +} +\end{ffcode} + +It may be represented in EO like this: + +\begin{ffcode} +[] > cart + memory > total + [i] > add + total.write > @ + total.add i.price +\end{ffcode} + +As the example demonstrates, the presence of generics in class declaration may be ignored, since EO is a language without types and type checking. + +\subsection{C++ Templates} +\label{sec:templates} + +Templates are a feature of the C++ programming language that allows functions and classes to operate with generic types, allowing a function or class to work on many different data types without being rewritten for each one. + +\begin{ffcode} +template T max(T a, T b) { + return a > b ? a : b; +} +int x = max(7, 42); +\end{ffcode} + +It may be represented in EO like this: + +\begin{ffcode} +[a b] > max + if. > @ + a.greater + a + b +max 7 42 > x +\end{ffcode} + +As the example demonstrates, the presence of templates may be ignored, since EO is a language without types and type checking. + +\subsection{Mixins} +\label{sec:mixins} + +A mixin is a class that contains methods for use by other classes without having to be the parent class of those other classes. The following code demonstrates how Ruby module is included into a class: + +\begin{ffcode} +module Timing + def recent? + @time - Time.now < 24 * 60 * 60 + end +end +def News + include Timing + def initialize(t) + @time = t + end +end +n = News.new(Time.now) +n.recent? +\end{ffcode} + +This code may be represented in EO by just copying the method \ff{recent?} to the object \ff{News} as if it was defined there. + +\subsection{Annotations} +\label{sec:annotations} + +In Java, an annotation is a form of syntactic metadata that can be added to source code; classes, methods, variables, parameters and Java packages may be annotated. Later, annotations may be retrieved through Reflection API. For example, this program analyzes the annotation attached to the class of the provided object and changes the behavior depending on one of its attributes: + +\begin{ffcode} +interface Item {} +@Ship(true) class Book { /*..*/ } +@Ship(false) class Song { /*..*/ } +class Cart { + void add(Item i) { + /* add the item to the cart */ + if (i.getClass() + .getAnnotation(Ship.class) + .value()) { + /* mark the cart as shippable */ + } + } +} +\end{ffcode} + +The code may be represented in EO using classes suggested in Sec.~\ref{sec:classes}: + +\begin{ffcode} +[] > Book + Ship true > a1 + [] > new + [] > @ +[] > Song + Ship false > a1 + [] > new + [] > @ +[] > Cart + [i] > add + seq > @ + "// Add the item to the cart" + if. + i.&.a1.value + "// Mark the cart shippable" + TRUE +\end{ffcode} + +Annotations become attributes of objects, which represent classes in EO, as explained in Sec.~\ref{sec:classes}: \ff{Book.a1} and \ff{Song.a1}. + +\section{Traceability} + +Certain amount of semantic information may be lost during the translation from a more powerful programming language to EO objects, such as, for example, namings, line numbers, comments, etc. Moreover, it may be useful to have an ability to trace EO objects back to original language constructs, which they were motivated by. For example, a simple C function: + +\begin{ffcode} +int f(int x) { + return 42 / x; +} +\end{ffcode} + +It may be mapped to the following EO object: + +\begin{ffcode} +[x] > f + [] > @ + "src/main.c:1-1" > source + 42.div x > @ + "src/main.c:0-2" > source +\end{ffcode} + +Here, synthetic \ff{source} attribute represents the location in the source code file with the original C code. It's important to make sure during translation that the name \ff{source} doesn't conflict with a possibly similar name in the object. + +\section{Conclusion} + +We demonstrated how some language features often present in high-level object-oriented languages, such as Java or C++, may be expressed using objects. We used EO as a destination programming language because of its minimalistic semantics: it doesn't have any language features aside from objects and their composition and decoration mechanisms. + +\bibliographystyle{ACM-Reference-Format} +\bibliography{main} + +\end{document}