objectionary/eo
1
1
Fork 0
mirror of https://github.com/objectionary/eo.git synced 2024-09-11 12:45:42 +03:00
Code Issues Projects Releases Wiki Activity

paper removed

Browse Source
This commit is contained in:
Yegor Bugayenko 2024-04-09 18:47:43 +03:00
parent 6f50ce2673
commit 073a1f8d1f
No known key found for this signature in database
GPG Key ID: B8283801026E65F3
24 changed files with 0 additions and 3678 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
.github/workflows/latexmk.yml vendored
View File

@ -1,21 +0,0 @@
name: latexmk
on:
push:
branches: master
paths: 'paper/**'
pull_request:
branches: master
paths: 'paper/**'
concurrency:
group: latexmk-${{ github.ref }}
cancel-in-progress: true
jobs:
latexmk:
runs-on: ubuntu-22.04
steps:
- uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4
- uses: yegor256/latexmk-action@0.11.1
with:
path: paper
opts: -pdf
depends: paper/DEPENDS.txt

19
paper/.gitignore vendored
View File

@ -1,19 +0,0 @@
.DS_Store
_minted-*
*.pdf
*.bbl
*.bcf
*.blg
*.fdb_latexmk
*.fls
*.log
*.run.xml
*.aux
*.pyg
*.out
*.synctex.gz
*.zip
package/
iexec.ret
*-SAVE-ERROR
_eolang/

2
paper/.latexmkrc
View File

@ -1,2 +0,0 @@
$pdflatex = 'pdflatex %O -interaction=errorstopmode -shell-escape -halt-on-error %S';
$success_cmd = 'texqc && texsc';

5
paper/.proselintrc
View File

@ -1,5 +0,0 @@
{
"checks": {
"typography.symbols.curly_quotes": false
}
}

16
paper/.texsc
View File

@ -1,16 +0,0 @@
--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,phigure
--ignore=tikz:op
--ignore=textcolor:pp
--ignore=newmdenv:op
--ignore=f,code,nospell,citet,citep

53
paper/DEPENDS.txt
View File

@ -1,53 +0,0 @@
hard acmart
hard algorithmicx
hard algpseudocodex
hard anyfontsize
hard babel-russian
hard biber
hard cancel
hard catchfile
hard cjk
hard cm-super
hard comment
hard csquotes
hard currfile
hard cyrillic
hard datetime
hard enumitem
hard environ
hard fdsymbol
hard ffcode
hard fmtcount
hard footmisc
hard framed
hard fvextra
hard href-ul
hard hyperxmp
hard hyphen-russian
hard iexec
hard ifmtarg
hard lastpage
hard lh
hard libertine
hard makecell
hard ncctools
hard paralist
hard pgf
hard pgfopts
hard preprint
hard stmaryrd
hard svg
hard textpos
hard tikzfill
hard titling
hard to-be-determined
hard totpages
hard transparent
hard trimspaces
hard upquote
hard wrapfig
hard xstring
hard cleveref
hard adjustbox
hard bibcop
hard silence

58
paper/Makefile
View File

@ -1,58 +0,0 @@
# The MIT License (MIT)
#
# Copyright (c) 2016-2024 Objectionary.com
#
# 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:
.PHONY: clean
SHELL=bash
TLROOT=$$(kpsewhich -var-value TEXMFDIST)
PACKAGES=ffcode to-be-determined href-ul iexec eolang bibcop
REPO=objectionary/eo
gsed=$(if $(shell which gsed),gsed,sed)
zip: *.tex sections/*.tex
rm -rf package
mkdir package
cd package
cp ../eolang-paper.tex .
cp ../phigure.sty .
cp ../main.bib .
for p in $(PACKAGES); do cp $(TLROOT)/tex/latex/$${p}/$${p}.sty .; done
cp -r ../sections .
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}|g" eolang-paper.tex
${gsed} -i "s|REPOSITORY|$(REPO)|g" eolang-paper.tex
pdflatex -shell-escape -halt-on-error eolang-paper.tex > /dev/null
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
zip -x eolang-paper.pdf -r paper-$${version}.zip *
mv paper-$${version}.zip ..
cd ..
clean:
git clean -dfX

29
paper/README.md
View File

@ -1,29 +0,0 @@
<img alt="logo" src="https://www.objectionary.com/cactus.svg" height="100px" />
[![arXiv](https://img.shields.io/badge/arXiv-2111.13384-green.svg)](https://arxiv.org/abs/2111.13384)
[![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
[LaTeX](https://www.latex-project.org/get/),
[`aspell`](http://aspell.net/),
[`jq`](https://stedolan.github.io/jq/),
[`biblint`](https://github.com/Kingsford-Group/biblint),
[`texsc`](https://rubygems.org/gems/texsc),
and
[`texqc`](https://rubygems.org/gems/texqc)
installed.
You may also want to check whether your LaTeX installation has
all the packages required [in here](https://github.com/objectionary/eo/blob/master/.github/workflows/latexmk.yml).
If you miss any of them, install, for example, with the help of
[`tlmgr`](https://tug.org/texlive/tlmgr.html).
Once compiled and packaged, upload zip archive to [arXiv](https://arxiv.org/abs/2111.13384).

60
paper/aspell.en.pws
View File

@ -1,60 +0,0 @@
personal_ws-1.1 en 741 utf-8
Yegor
Bugayenko
EOLANG
Huawei
boolean
destructors
runtime
prepended
varargs
getters
mixins
whitespace
MySQL
reusability
Simula
LLVM
GraalVM
Smalltalk
Pharo
OCaml
polymorphism
EBNF
instantiation
modularity
superclasses
superclass
Rubocop
Checkstyle
ctor
ctors
NULLs
dataization
vectorization
metas
untab
ISBN
decomposable
cardinality
ANTLR
XSLT
objectionary
bytecode
OpenJDK
classpath
vertice
stylesheets
xshift
yshift
stdout
arity
XMIR
eXtensible
SODGs
GOTO
unary
decoratee
cmtt
attr
acmart

188
paper/eolang-paper.tex
View File

@ -1,188 +0,0 @@
% The MIT License (MIT)
%
% Copyright (c) 2016-2024 Objectionary.com
%
% 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.
\documentclass[sigplan,nonacm]{acmart}
\settopmatter{printfolios=false,printccs=false,printacmref=false}
\usepackage[utf8]{inputenc}
\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}
\usepackage[russian,english]{babel}
\renewcommand\ttdefault{cmtt}
\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
\usepackage{tcolorbox} % for algorithm
\tcbuselibrary{skins}
\usepackage{algpseudocode} % for algorithms
\usepackage{multicol} % for two cols in BNF
\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}
\newcommand\nospell[1]{#1}
\newcommand\br{\\[-4pt]}
\newcommand\figcap[1]{\caption{#1}\Description{#1}}
\newcommand\lref[1]{the line no.~\ref{ln:#1}}
\newcommand\lrefs[2]{the lines~\ref{ln:#1}--\ref{ln:#2}}
\newenvironment{twocols}{}{}
\newcounter{rule}
\renewcommand\therule{R\arabic{rule}}
\newcommand\rr{\triangleright{}}
\newcommand\rrule[1]{{\scshape\sffamily\ref{rule:#1}}}
\newcommand{\jrule}[1]{%
\refstepcounter{rule}\label{rule:#1}%
\text{\textbf{\rrule{#1}}}}
\newcommand*{\ohat}[2]{%
\overbracket[0.4pt][2pt]{\textcolor{black}{#2}}^{\color{gray}#1}}
\newenvironment{algo}
{\newcommand\kw[1]{{\bfseries\sffamily ##1}}
\newcommand\tab{{\hspace*{1em}}}
\noindent}
{}
\setlength{\footskip}{13.0pt}
\acmBooktitle{untitled}
\title{EOLANG and \texorpdfstring{\(\varphi\)}{phi}-calculus}
\subtitle{%
Ver:
\texorpdfstring{
\href{https://github.com/REPOSITORY/releases/tag/0.0.0}
{\ff{0.0.0}}
}{0.0.0}
}
\author{Yegor Bugayenko}
\orcid{0000-0001-6370-0678}
\email{yegor256@gmail.com}
\affiliation{
\institution{Huawei}
\city{Moscow}
\country{Russia}
}
\ccsdesc[300]{Software and its engineering~Software notations and tools~Formal language definitions}
\keywords{Object-Oriented Programming, Object Calculus}
\begin{document}
\begin{abstract}
Object-oriented programming (OOP) is one of the most popular
paradigms used for building software systems\footnote{%
\LaTeX{} sources of this paper are maintained in
\href{https://github.com/REPOSITORY}{REPOSITORY} GitHub repository,
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
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 \eolang{}), an experimental
programming language based on \phic{}.
\end{abstract}
\maketitle
\section{Introduction}
\label{sec:intro}
\input{sections/intro}
\input{sections/overview}
The rest of the paper is dedicated to the discussion of the
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 \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
formalization of OOP.
\section{Syntax}
\label{sec:syntax}
\input{sections/syntax}
\section{Calculus}
\label{sec:calculus}
\input{sections/calculus}
% \section{Semantics}
% \label{sec:semantics}
% \input{sections/semantics}
% \section{Pragmatics}
% \label{sec:pragmatics}
% \input{sections/pragmatics}
% \section{XMIR}
% \label{sec:xmir}
% \input{sections/xmir}
\section{Key Features}
\label{sec:features}
\input{sections/features}
\section{Four Principles of OOP}
\label{sec:four}
\input{sections/four}
\section{Complexity}
\label{sec:complexity}
\input{sections/complexity}
\section{Related Work}
\label{sec:related}
\input{sections/related}
\section{Acknowledgments}
\input{sections/acks}
{\raggedright
\bibliographystyle{ACM-Reference-Format}
\bibliography{main}}
\clearpage
\end{document}

802
paper/main.bib
View File

@ -1,802 +0,0 @@
@misc{erlang2020manual,
organization = {Ericsson AB},
title = {{{Erlang/OTP} System Documentation}},
year = {2020},
}
@inproceedings{usov2020,
author = {Usov, Artem and Dardha, Prnela},
booktitle = {{Proceedings of the Coordination Models and Languages. {COORDINATION} 2020}},
title = {{{SJF:} an Implementation of Semantic Featherweight Java}},
volume = {12134},
year = {2020},
}
@article{bright2020origins,
author = {Bright, Walter and Alex and rescu, Andrei and Parker, Michael},
journal = {{ACM on Programming Languages}},
title = {{Origins of the D Programming Language}},
volume = {4},
year = {2020},
}
@article{coblenz2019,
author = {Coblenz, Michael J. and Oei, Reed and Etzel, Tyler and Koronkevich, Paulette and Baker, Miles and Bloem, Yannick and Myers, Brad A. and Sunshine, Joshua and Aldrich, Jonathan},
journal = {{CoRR}},
title = {{Obsidian: Typestate and Assets for Safer Blockchain Programming}},
volume = {1},
year = {2019},
}
@book{jdk8,
author = {Schildt, Herbert},
publisher = {McGraw-Hill Education},
title = {{Java: the Complete Reference, Eleventh Edition}},
year = {2018},
}
@inproceedings{bi2018typed,
author = {Bi, Xuan and Oliveira, Bruno C. d S.},
booktitle = {{Proceedings of the European Conference on Object-Oriented Programming}},
title = {{Typed First-Class Traits}},
year = {2018},
}
@inproceedings{rocha2018javaexception,
author = {Rocha, Jonathan and Melo, Hugo and Coelho, Roberta and Sena, Bruno},
booktitle = {{Proceedings of the 25th Conference on Pattern Languages of Programs}},
title = {{Towards a Catalogue of Java Exception Handling Bad Smells and Refactorings}},
year = {2018},
}
@article{khanam2018,
author = {Khanam, Zeba},
journal = {{International Journal on Future Revolution in Computer Science \& Communication Engineering}},
title = {{Barriers to Refactoring: Issues and Solutions}},
volume = {4},
year = {2018},
}
@book{jemerov2017kotlin,
author = {Jemerov, Dmitry and Isakova, Svetlana},
publisher = {Manning Publications Company},
title = {{Kotlin in Action}},
year = {2017},
}
@misc{gannimo2017typeconfusion,
author = {Gannimo},
title = {{Type Confusion: Discovery, Abuse, and Protection}},
year = {2017},
}
@book{eo2,
author = {Bugayenko, Yegor},
publisher = {Amazon},
title = {{Elegant Objects}},
year = {2017},
}
@book{ierusalimschy2016lua,
author = {Ierusalimschy, Roberto},
publisher = {Lua.Org},
title = {{Programming in Lua, Fourth Edition}},
year = {2016},
}
@book{bloch2016effective,
author = {Bloch, Joshua},
publisher = {Pearson Education India},
title = {{Effective Java}},
year = {2016},
}
@book{eo1,
author = {Bugayenko, Yegor},
publisher = {Amazon},
title = {{Elegant Objects}},
year = {2016},
}
@book{bernstein2016legacy,
author = {Bernstein, David Scott},
publisher = {Pragmatic Bookshelf},
title = {{Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software}},
year = {2016},
}
@book{donovankernighan2015go,
author = {Donovan, Alan A.A. and Kernighan, Brian W.},
publisher = {Addison-Wesley Professional},
title = {{The Go Programming Language}},
year = {2015},
}
@article{shelly2015flaws,
author = {Shelly, Asaf},
title = {{Flaws of Object Oriented Modeling}},
year = {2015},
}
@book{nielson2015principles,
author = {Nielson, Flemming and Nielson, Hanne R. and Hankin, Chris},
publisher = {Springer},
title = {{Principles of Program Analysis}},
year = {2015},
}
@article{matsakis2014rust,
author = {Matsakis, Nicholas D. and Klock, Felix S.},
journal = {{ACM SIGADA Ada Letters}},
number = {3},
title = {{The Rust Language}},
volume = {34},
year = {2014},
}
@inproceedings{burton2014using,
author = {Burton, Eden and Sekerinski, Emil},
booktitle = {{Proceedings of the European Conference on Pattern Languages of Programs}},
title = {{Using Dynamic Mixins to Implement Design Patterns}},
year = {2014},
}
@book{nystrom2014game,
author = {Nystrom, R.},
publisher = {Genever Benning},
title = {{Game Programming Patterns}},
year = {2014},
}
@book{jech2013set,
author = {Jech, Thomas},
publisher = {Springer Science \& Business Media},
title = {{Set Theory}},
year = {2013},
}
@book{lutz2013learning,
author = {Lutz, Mark},
publisher = {O'Reilly Media},
title = {{Learning Python: Powerful Object-Oriented Programming}},
year = {2013},
}
@misc{bezanson2012julia,
author = {Bezanson, Jeff and Karpinski, Stefan and Shah, Viral B. and Edelman, Alan},
title = {{Julia: a Fast Dynamic Language for Technical Computing}},
year = {2012},
}
@book{liang2012,
author = {Liang, Y. Daniel},
publisher = {Pearson Education, Inc.},
title = {{Introduction to Java Programming: Brief Version}},
year = {2012},
}
@book{barendregt2012,
author = {Barendregt, Hendrik P.},
publisher = {College Publications},
title = {{The Lambda Calculus: Its Syntax and Semantics}},
year = {2012},
}
@article{bettinibono2008delegation,
author = {Bettini, Lorenzo and Bono, Viviana and Venneri, Betti},
journal = {{Science of Computer Programming}},
title = {{Delegation by Object Composition}},
volume = {76},
year = {2011},
}
@inproceedings{schmager2010gohotdraw,
author = {Schmager, Frank and Cameron, Nicholas and Noble, James},
booktitle = {{Proceedings of the {PLATEAU'10:} Evaluation and Usability of Programming Languages and Tools}},
title = {{{GoHotDraw:} Evaluating the Go Programming Language With Design Patterns}},
year = {2010},
}
@inproceedings{richards2010analysis,
author = {Richards, Gregor and Lebresne, Sylvain and Burg, Brian and Vitek, Jan},
booktitle = {{Proceedings of the Conference on Programming Language Design and Implementation}},
title = {{An Analysis of the Dynamic Behavior of {JavaScript} Programs}},
year = {2010},
}
@article{armstrong2010erlang,
author = {Armstrong, Joe},
journal = {{Communications of the ACM}},
number = {9},
title = {{Erlang}},
volume = {53},
year = {2010},
}
@article{nierstrasz2010ten,
author = {Nierstrasz, Oscar Marius},
journal = {{Journal of Object Technology}},
number = {5},
title = {{Ten Things I Hate About Object-Oriented Programming}},
volume = {9},
year = {2010},
}
@book{metula2010managed,
author = {Metula, Erez},
publisher = {Elsevier},
title = {{Managed Code Rootkits: Hooking into Runtime Environments}},
year = {2010},
}
@misc{hoare2009null,
author = {Hoare, Tony},
title = {{Null References: the Billion Dollar Mistake}},
year = {2009},
}
@book{martin2008cleancode,
author = {Martin, Robert C.},
publisher = {Prentice Hall PTR},
title = {{Clean Code: a Handbook of Agile Software Craftsmanship}},
year = {2008},
}
@book{deitel2007java,
author = {Deitel, Harvey M. and Deitel, Paul J.},
publisher = {Prentice Hall},
title = {{Java How to Program}},
year = {2007},
}
@article{ciaffaglione2007theory_of_contexts,
author = {Ciaffaglione, Alberto and Liquori, Luigi and Miculan, Marino},
journal = {{Journal of Automated Reasoning}},
title = {{Reasoning About Object-Based Calculi in (Co)In\-du\-cti\-ve Type Theory and the Theory of Contexts}},
volume = {39},
year = {2007},
}
@misc{grady2007object,
author = {Booch, Grady and Maksimchuk, Robert A. and Engle, Michael and Young, Bobbi and Conallen, Jim and Houston, Kelli},
publisher = {Addison-Wesley Professional},
title = {{Object-Oriented Analysis and Design With Applications}},
year = {2007},
}
@book{goetz2006java,
author = {Goetz, Brian and Peierls, Tim and Lea, Doug and Bloch, Joshua and Bowbeer, Joseph and Holmes, David},
publisher = {Pearson Education},
title = {{Java Concurrency in Practice}},
year = {2006},
}
@book{eckel2006thinking,
author = {Eckel, Bruce},
publisher = {Prentice Hall},
title = {{Thinking in Java}},
year = {2006},
}
@article{armstrong2006quarks,
author = {Armstrong, Deborah J.},
journal = {{Communications of the ACM}},
number = {2},
title = {{The Quarks of Object-Orien\-Ted Development}},
volume = {49},
year = {2006},
}
@article{jagannathan2005transactional,
author = {Jagannathan, Suresh and Vitek, Jan and Welc, Adam and Hosking, Antony},
journal = {{Science of Computer Programming}},
number = {2},
title = {{A Transactional Object Calculus}},
volume = {57},
year = {2005},
}
@misc{fluentinterface,
author = {Fowler, Martin},
url = {https://www.martinfowler.com/bliki/FluentInterface.html},
year = {2005},
}
@misc{holub2004more,
author = {Holub, Allen},
title = {{More on Getters and Setters}},
year = {2004},
}
@book{mcconnell2004codecomplete,
author = {McConnell, Steve},
publisher = {Microsoft Press},
title = {{Code Complete, Second Edition}},
year = {2004},
}
@book{west2004object,
author = {West, David},
publisher = {Pearson Education},
title = {{Object Thinking}},
year = {2004},
}
@book{graham2004hackers,
author = {Graham, Paul},
publisher = {O'Reilly Media},
title = {{Hackers \& Painters: Big Ideas From the Computer Age}},
year = {2004},
}
@article{birka2004practical,
author = {Birka, Adrian and Ernst, Michael D.},
journal = {{ACM SIGPLAN Notices}},
number = {10},
title = {{A Practical Type System and Language for Reference Immutability}},
volume = {39},
year = {2004},
}
@misc{holub2003extends,
author = {Holub, Allen},
title = {{Why Extends Is Evil}},
year = {2003},
}
@inproceedings{ciaffaglione2003typetheories,
author = {Ciaffaglione, Alberto and Liquori, Luigi and Miculan, Marino},
booktitle = {{Proceedings of the International Conference on Logic for Programming Artificial Intelligence and Reasoning}},
title = {{Imperative Object-Based Calculi in Co-Inductive Type Theories}},
year = {2003},
}
@article{jankowska2003anotheroop,
author = {Jankowska, Beata},
journal = {{Control and Cybernetics}},
title = {{Yet Another Object-Oriented Data Model and Its Application}},
volume = {32},
year = {2003},
}
@inproceedings{ciaffaglione2003reasoning,
author = {Ciaffaglione, Alberto and Liquori, Luigi and Miculan, Marino},
booktitle = {{Proceedings of the {MERLIN'03:} Proceedings of the 2003 {ACM} {SIGPLAN} Workshop on Mechanized Reasoning About Languages With Variable Binding}},
title = {{Reasoning on an Imperative Object-Based Calculus in Higher Order Abstract Syntax}},
year = {2003},
}
@misc{eden2002visual,
author = {Eden, Amnon},
publisher = {Citeseer},
title = {{A Visual Formalism for Object-Oriented Architecture}},
year = {2002},
}
@misc{lattner2002llvm,
author = {Lattner, Chris Arthur},
title = {{{LLVM:} an Infrastructure for Multi-Stage Optimization}},
year = {2002},
}
@book{metsker2002,
author = {Metsker, Steven John},
publisher = {Addison-Wesley},
title = {{Design Patterns Java Workbook}},
year = {2002},
}
@inproceedings{eden2001principles,
author = {Eden, Amnon H. and Hirshfeld, Yoram},
booktitle = {{Proceedings of the {CASCON'01:} Proceedings of the 2001 Conference of the Centre for Advanced Studies on Collaborative Research}},
title = {{Principles in Formal Specification of Object-Oriented Architectures}},
year = {2001},
}
@article{igarashi2001featherweight,
author = {Igarashi, Atsushi and Pierce, Benjamin C. and Wadler, Philip},
journal = {{ACM Transactions on Programming Languages and Systems}},
number = {3},
title = {{Featherweight Java: a Minimal Core Calculus for Java and {GJ}}},
volume = {23},
year = {2001},
}
@inproceedings{alpern2001efficient,
author = {Alpern, Bowen and Cocchi, Anthony and Fink, Stephen and Grove, David},
booktitle = {{Proceedings of the Conference on Object-Oriented Programming, Systems, Languages, and Applications}},
title = {{Efficient Implementation of Java Interfaces: Invokeinterface Considered Harmless}},
year = {2001},
}
@book{hunt2000,
author = {Hunt, John},
publisher = {Springer},
title = {{Inheritance Considered Harmful}},
year = {2000},
}
@book{duke1991object,
author = {Duke, Roger and King, Paul and Rose, Gordon and Smith, Graeme},
publisher = {Citeseer},
title = {{The Object-Z Specification Language}},
year = {2000},
}
@inproceedings{jeffrey1999distributed,
author = {Jeffrey, Alan},
booktitle = {{Proceedings of {FOOL}}},
title = {{A Distributed Object Calculus}},
year = {1999},
}
@misc{paige1999object,
author = {Paige, Richard F. and Ostroff, Jonathan S.},
title = {{An Object-Oriented Refinement Calculus}},
year = {1999},
}
@misc{gordon1998concurrent,
author = {Gordon, Andy and Hankin, Paul D.},
title = {{A Concurrent Object Calculus: Reduction and Typing}},
year = {1998},
}
@inproceedings{mikhajlov1998study,
author = {Mikhajlov, Leonid and Sekerinski, Emil},
booktitle = {{Proceedings of the European Conference on Object-Oriented Programming}},
title = {{A Study of the Fragile Base Class Problem}},
year = {1998},
}
@inproceedings{bono1998imperative,
author = {Bono, Viviana and Fisher, Kathleen},
booktitle = {{Proceedings of the European Conference on Object-Oriented Programming}},
title = {{An Imperative, First-Order Calculus With Object Extension}},
year = {1998},
}
@article{seiter1998evolution,
author = {Seiter, Linda M. and Palsberg, Jens and Lieberherr, Karl J.},
journal = {{IEEE Transactions on Software Engineering}},
number = {1},
title = {{Evolution of Object Behavior Using Context Relations}},
volume = {24},
year = {1998},
}
@inproceedings{di1998lambda,
author = {Di Gianantonio, Pietro and Honsell, Furio and Liquori, Luigi},
booktitle = {{Proceedings of the Conference on Object-Oriented Programming, Systems, Languages, and Applications}},
title = {{A Lambda Calculus of Objects With Self-Inflicted Extension}},
year = {1998},
}
@book{hunt1997smalltalk,
author = {Hunt, John},
publisher = {Springer Science \& Business Media},
title = {{Smalltalk and Object Orientation: an Introduction}},
year = {1997},
}
@book{meyer1997object,
author = {Meyer, Bertr},
publisher = {Prentice Hall},
title = {{Object-Oriented Software Construction}},
year = {1997},
}
@misc{kay97keynote,
author = {Kay, Alan},
title = {{The Computer Revolution Hasn't Happened yet}},
year = {1997},
}
@misc{bosch1997object,
author = {Bosch, Jan},
title = {{Object-Oriented Frameworks: Problems \& Experiences}},
year = {1997},
}
@inproceedings{czarnecki1997beyond,
author = {Czarnecki, Krzysztof and Eisenecker, Ulrich W. and Steyaert, Patrick},
booktitle = {{Proceedings of the European Conference on Object-Oriented Programming}},
title = {{Beyond Objects: Generative Programming}},
year = {1997},
}
@article{carter1997oopvsr,
author = {Carter, Jeffrey},
journal = {{ACM SIGADA Ada Letters}},
title = {{{OOP} Vs. Readability}},
volume = {XVII},
year = {1997},
}
@book{beck1997smalltalk,
author = {Beck, Kent},
publisher = {Prentice Hall},
title = {{Smalltalk Best Practice Patterns}},
year = {1997},
}
@book{martin1997pattern,
author = {Martin, Robert C. and Riehle, Dirk and Buschmann, Frank},
publisher = {Addison-Wesley},
title = {{Pattern Languages of Program Design 3}},
year = {1997},
}
@book{stroustrup1997,
author = {Stroustrup, Bjarne},
publisher = {Addison-Wesley Professional},
title = {{The C++ Programming Language}},
year = {1997},
}
@misc{giger1996object,
author = {Giger, Emanuel and Gall, Harald},
title = {{Object-Oriented Design Heuristics}},
year = {1996},
}
@article{leekwakryu1996transform,
author = {Lee, Kwak and Ryu, Hong-Ro, Hoon-Sung and Keun-Ho},
journal = {{The Transactions of the Korea Information Processing Society}},
title = {{A Translation of an Object Calculus into an Object Algebra}},
volume = {3},
year = {1996},
}
@article{madsen1995open,
author = {Madsen, Ole Lehrmann},
journal = {{Software: Practice and Experience}},
number = {S4},
publisher = {Wiley Online Library},
title = {{Open Issues in Object-Oriented Programming---A Scandinavian Perspective}},
volume = {25},
year = {1995},
}
@article{gosling1995java,
author = {Gosling, James and McGilton, Henry},
journal = {{Sun Microsystems Computer Company}},
title = {{The Java Language Environment}},
volume = {2550},
year = {1995},
}
@article{abadi1995imperative,
author = {Abadi, Mart\'in and Cardelli, Luca},
journal = {{Theory and Practice of Object Systems}},
number = {3},
publisher = {Wiley Online Library},
title = {{An Imperative Object Calculus}},
volume = {1},
year = {1995},
}
@inproceedings{fisher1995delegation,
author = {Fisher, Kathleen and Mitchell, John C.},
booktitle = {{Proceedings of the International Symposium on Fundamentals of Computation Theory}},
title = {{A Delegation-Based Object Calculus With Subtyping}},
year = {1995},
}
@book{gamma1994design,
author = {Gamma, Erich and Helm, Richard and Johnson, Ralph and Vlissides, John},
publisher = {Addison Wesley},
title = {{Design Patterns: Elements of Reusable Object-Oriented Software}},
year = {1994},
}
@misc{cheon1994quick,
author = {Cheon, Yoonsik and Leavens, Gary T.},
title = {{A Quick Overview of {Larch/C++}}},
year = {1994},
}
@inproceedings{mitchell1993lambda,
author = {Mitchell, John C. and Honsell, Furio and Fisher, Kathleen},
booktitle = {{Proceedings of the {IEEE} Symposium on Logic in Computer Science}},
title = {{A Lambda Calculus of Objects and Method Specialization}},
year = {1993},
}
@inproceedings{jones1993pi,
author = {Jones, Cliff B.},
booktitle = {{Proceedings of the International Conference on Concurrency Theory}},
title = {{A Pi-Calculus Semantics for an Object-Based Design Notation}},
year = {1993},
}
@inproceedings{durr1992vdm,
author = {Durr, Eugene and Van Katwijk, Jan},
booktitle = {{Proceedings Computer Systems and Software Engineering}},
title = {{{VDM++,} a Formal Specification Language for Object-Oriented Designs}},
year = {1992},
}
@inproceedings{nierstrasz1991towards,
author = {Nierstrasz, Oscar},
booktitle = {{Proceedings of the European Conference on Object-Oriented Programming}},
title = {{Towards an Object Calculus}},
year = {1991},
}
@inproceedings{honda1991object,
author = {Honda, Kohei and Tokoro, Mario},
booktitle = {{Proceedings of the European Conference on Object-Oriented Programming}},
title = {{An Object Calculus for Asynchronous Communication}},
year = {1991},
}
@book{steele1990common,
author = {Steele, Guy},
publisher = {Elsevier},
title = {{Common {LISP:} the Language}},
year = {1990},
}
@inproceedings{duke1990towards,
author = {Duke, David and Duke, Roger},
booktitle = {{Proceedings of the International Symposium of {VDM} Europe}},
title = {{Towards a Semantics for Object-Z}},
year = {1990},
}
@misc{nierstrasz1989survey,
author = {Nierstrasz, Oscar},
title = {{A Survey of Object-Oriented Concepts}},
year = {1989},
}
@inproceedings{madsen1988object,
author = {Madsen, Ole Lehrmann and M{\o}ller-Pedersen, Birger},
booktitle = {{Proceedings of the European Conference on Object-Oriented Programming}},
title = {{What Object-Oriented Programming May Be-And What It Does Not Have to Be}},
year = {1988},
}
@inproceedings{ungar1987self,
author = {Ungar, David and Smith, R. and all B.},
booktitle = {{Proceedings of the {ACM} {SIGPLAN} Conference on Object-Oriented Programming Systems, Languages and Applications}},
title = {{Self: the Power of Simplicity}},
year = {1987},
}
@misc{kaymaster68,
author = {Kay, Alan},
title = {{{FLEX---A} Flexible Extendable Language}},
year = {1986},
}
@inproceedings{bancilhon1985calculus,
author = {Bancilhon, Francois and Khoshafian, Setrag},
booktitle = {{Proceedings of the Symposium on Principles of Database Systems}},
title = {{A Calculus for Complex Objects}},
year = {1985},
}
@article{stefik1985object,
author = {Stefik, Mark and Bobrow, Daniel G.},
journal = {{AI Magazine}},
number = {4},
title = {{Object-Oriented Programming: Themes and Variations}},
volume = {6},
year = {1985},
}
@book{goldbergrobson1983smalltalk,
author = {Goldberg, Adele and Robson, David},
publisher = {Addison-Wesley},
title = {{Smalltalk-80: the Language and Its Implementation}},
year = {1983},
}
@article{rentsch1982object,
author = {Rentsch, Tim},
journal = {{ACM SIGPLAN Notices}},
number = {9},
title = {{Object Oriented Programming}},
volume = {17},
year = {1982},
}
@book{dijkstra1982role,
author = {Dijkstra, Edsger W.},
publisher = {Springer Verlag},
title = {{On the Role of Scientific Thought}},
year = {1982},
}
@book{yourdon1979structured,
author = {Yourdon, Edward and Constantine, Larry L.},
publisher = {Prentice-Hall},
title = {{Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design}},
year = {1979},
}
@article{backus1978,
author = {Backus, John},
journal = {{Communications of the ACM}},
number = {8},
title = {{Can Programming Be Liberated From the Von Neumann Style? a Functional Style and Its Algebra of Programs}},
volume = {21},
year = {1978},
}
@article{goodenough1975exception,
author = {Goodenough, John B.},
journal = {{Communications of the ACM}},
number = {12},
title = {{Exception Handling: Issues and a Proposed Notation}},
volume = {18},
year = {1975},
}
@article{landin1966next,
author = {Landin, Peter J.},
journal = {{Communications of the ACM}},
number = {3},
title = {{The Next 700 Programming Languages}},
volume = {9},
year = {1966},
}
@article{dahl1966simula,
author = {Dahl, Ole-Johan and Nygaard, Kristen},
journal = {{Communications of the ACM}},
number = {9},
title = {{{SIMULA:} an {ALGOL-based} Simulation Language}},
volume = {9},
year = {1966},
}
@article{algol60,
author = {Backus, John W. and Bauer, Friedrich L. and Green, Julien and Katz, Charles and McCarthy, John and Perlis, Alan J. and Rutishauser, Heinz and Samelson, Klaus and Vauquois, Bernard and Wegstein, Joseph Henry and others},
journal = {{Communications of the ACM}},
number = {5},
title = {{Report on the Algorithmic Language {ALGOL} 60}},
volume = {3},
year = {1960},
}
@misc{lukasiewicz1951aristotle,
author = {Lukasiewicz, Jan},
title = {{Aristotle's Syllogistic From the Standpoint of Modern Formal Logic}},
year = {1951},
}
@article{church1932set,
author = {Church, Alonzo},
journal = {{Annals of Mathematics}},
number = {2},
title = {{A Set of Postulates for the Foundation of Logic}},
volume = {33},
year = {1932},
}
@book{lucas1891theorie,
author = {Lucas, Edouard},
publisher = {Gauthier-Villars},
title = {{{Th{\'e}orie} Des Nombres}},
year = {1891},
}
@misc{czaplicki_elmguide,
author = {Czaplicki, Evan},
title = {{Elm, Official Guide}},
url = {https://guide.elm-lang.org/error_handling/},
}
@article{danforth1988type,
author = {Danforth, Scott and Tomlinson, Chris},
journal = {{ACM Computing Surveys}},
number = {1},
pages = {29--72},
title = {{Type Theories and Object-Oriented Programming}},
volume = {20},
year = {1988},
}

57
paper/phigure.sty
View File

@ -1,57 +0,0 @@
% The MIT License (MIT)
%
% Copyright (c) 2016-2024 Objectionary.com
%
% 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.
\NeedsTeXFormat{LaTeX2e}
\ProvidesPackage{phigure}[00.00.0000 0.0.0 Phi Figures]
\RequirePackage{tikz}
\usetikzlibrary{arrows}
\usetikzlibrary{shapes}
\usetikzlibrary{decorations}
\usetikzlibrary{decorations.pathmorphing}
\usetikzlibrary{intersections}
\usetikzlibrary{positioning}
\usetikzlibrary{backgrounds}
\usetikzlibrary{calc}
\usetikzlibrary{shapes.arrows}
\newenvironment{phigure}%
{\noindent\begin{tikzpicture}[om,pics/parallel arrow/.style={code={\draw[-latex,rho] (##1) -- (-##1);}}]}%
{\end{tikzpicture}}
\tikzstyle{om} = [->,>=stealth',node distance=2.5cm,thick]
\tikzstyle{thing} = [thick,inner sep=0pt,minimum height=2.4em,draw,font={\small}]
\tikzstyle{object} = [thing,circle]
\tikzstyle{data} = [thing,regular polygon,regular polygon sides=8]
\tikzstyle{dup} = [thing,rectangle,draw=none,minimum height=1.5em,inner sep=3pt]
\tikzstyle{empty} = [object]
\tikzstyle{transforms} = [fill=white!80!black, single arrow, minimum height=0.5cm, minimum width=0.5cm,single arrow head extend=2mm]
\tikzstyle{rho} = [draw,decorate,decoration={snake,amplitude=.4mm,segment length=2mm,post length=1mm}]
\tikzstyle{ref} = []
\tikzstyle{edge-name} = [circle,font=\scriptsize,near start,sloped,fill=white,inner sep=0pt,sloped/.append style={transform shape}]
\tikzstyle{parent} = [draw,dotted]
\tikzstyle{atom} = [object,double]
\tikzstyle{lambda} = [xshift=-5pt,yshift=3pt,draw,fill=white,rectangle,thin,minimum width=1.2em,anchor=north west,font={\scriptsize}]
\tikzstyle{attr} = [midway,sloped,inner sep=0pt,above=2pt,sloped/.append style={transform shape},font={\scriptsize},color=black]
\tikzstyle{locator} = [attr,below=2pt]
\endinput

30
paper/sections/acks.tex
View File

@ -1,30 +0,0 @@
Many thanks to (in alphabetic order of last names)
\nospell{Fabricio Cabral},
\nospell{Kirill Chernyavskiy},
\nospell{Piotr Chmielowski},
\nospell{Danilo Danko},
\nospell{Konstantin Gukov},
\nospell{Andrew Graur},
\nospell{Ali-Sultan Ki-giz\-ba\-ev},
\nospell{Nikolai Ku\-da\-sov},
\nospell{Alexander Legalov},
\nospell{Tymur \(\lambda\)ysenko},
\nospell{Alexandr Naumchev},
\nospell{Alonso A. Ortega},
\nospell{John Page},
\nospell{Alex Panov},
\nospell{Alexander Pushkarev},
\nospell{Marcos Douglas B. Santos},
\nospell{Alex Semenyuk},
\nospell{Violetta Sim},
\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{Vladimir Zakharov}
for their contribution to the development of \eolang{} and \phic{}.

344
paper/sections/calculus.tex
View File

@ -1,344 +0,0 @@
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.
The rest of the section contains formal definitions of
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.
\end{definition}
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
\begin{equation}\label{eq:book}
\begin{split}
\ff{book} & = \left\{\begin{matrix*}[l]
(\ff{isbn}, \varnothing) \\
\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~\cref{def:object}.
\begin{definition}\label{def:data}
An object may have properties of \textbf{data},
which is a computation platform dependable entity and is not
decomposable any further within the scope of \phic{}.
\end{definition}
What exactly is data may depend on the
implementation platform, but most certainly would include
byte arrays, integers, floating-point numbers,
string literals, and boolean values.
The object at \lrefs{book2}{book2-end} may be represented as
\begin{equation}\label{eq:book2}
\begin{split}
\ff{book2} & = \left\{\begin{matrix*}[l]
(\ff{isbn}, \varnothing) \\
(\ff{title}, \ff{"Object Thinking"}) \\
(\ff{price}, \ff{memory}) \\
\end{matrix*}\right\}, \\
\end{split}
\end{equation}
where \ff{isbn}, \ff{title}, and \ff{price} are identifiers,
\ff{memory} is an object defined somewhere else,
and the text in double quotes is data.
\subsection{Attributes}
\begin{definition}\label{def:attribute}
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 \cref{eq:book2}, identifiers \ff{isbn}, \ff{title}, and \ff{price}
are the attributes of the object \ff{book2}.
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\);
this referencing mechanism is called \textbf{dot notation}.
\end{definition}
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
``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\).
\end{definition}
For example, the scope of the object at~\cref{eq:book2} consists of three identifiers:
\ff{isbn}, \ff{title}, and \ff{price}.
\subsection{Formation}
\begin{definition}\label{def: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 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
& \quad \ff{title} \mapsto \ff{"Object Thinking"}, \br
& \quad \ff{price} \mapsto \ff{memory} \br
& \rrbracket. \\
\end{split}
\end{equation}
\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.
\end{definition}
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 void before, become attached.
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 void attributes are substituted with \emph{arguments} during copying,
a newly created object will be \emph{closed}.
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 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}
& \ff{point}(\ff{x} \mapsto \ff{5}, \ff{y} \mapsto \ff{-3}).\ff{distance}(\br
& \quad \ff{to} \mapsto \ff{point}(\ff{x} \mapsto \ff{13}, \ff{y} \mapsto \ff{3.9}) \br
& ),
\end{split}
\end{equation}
and may further be simplified since the order of parameters is obvious:
\begin{equation}
\begin{split}
\ff{point}(\ff{5}, \ff{-3}).\ff{distance}(\ff{point}(\ff{13}, \ff{3.9})).
\end{split}
\end{equation}
An application without arguments is a copy of an object. For example,
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}
& \ff{p} \mapsto \ff{point}(\ff{5}, \ff{-3}),\\
& \ff{p1} \mapsto \ff{p},\\
& \ff{p2} \mapsto \ff{p}().\\
\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 \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\):
\begin{equation*}
x \mapsto [[ y -> t ]].
\end{equation*}
\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\).
\end{definition}
An object may be created either by
abstraction or application. In case of abstraction, an object
is created by another abstract object, for example:
\begin{equation}
\begin{split}
& x \mapsto \llbracket y \mapsto \llbracket z \mapsto t \rrbracket \rrbracket \br
& x.y.\rho = x \br
& x.y.z.\rho = y.
\end{split}
\end{equation}
In case of application, an object is created by the prepending object:
\begin{equation}
\begin{split}
& a \mapsto \llbracket b \mapsto c, d \mapsto e.f, g \mapsto h.i(j) \rrbracket \br
& a.b.\rho = a \br
& a.d.\rho = e \br
& a.g.\rho = h.
\end{split}
\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.
\end{definition}
For example:
\begin{equation}
\begin{split}
& x \mapsto \llbracket y(f) \mapsto \llbracket \rrbracket \rrbracket \br
& x.y.\rho = x \br
& z \mapsto \llbracket t \mapsto x.y(42) \rrbracket \br
& z.t.\rho = z \br
& z.t.\sigma = x.
\end{split}
\end{equation}
\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\).
\end{definition}
Here, \(\varphi\) is a special identifier denoting the object,
known as a \emph{decoratee}, being decorated
within the scope of the decorator.
For example, the object at \lrefs{circle}{circle-end} would
be denoted by this formula:
\begin{equation}\label{eq:c-empty}
\begin{split}
& \ff{circle}(\ff{center}, \ff{radius}) \mapsto \llbracket \br
& \quad \varphi \mapsto \ff{center}, \br
& \quad \ff{is-inside}(\ff{p}) \mapsto \llbracket \br
& \quad \quad \varphi \mapsto \rho.\varphi.\ff{distance}(\ff{p}).\ff{lte}(\ff{radius}) \br
& \quad \rrbracket \br
& \rrbracket,
\end{split}
\end{equation}
while the application of it would look like:
\begin{equation}
\begin{split}
\ff{c} & \mapsto \ff{circle}(\ff{point}(\ff{-3}, \ff{9}), \ff{40}),
\end{split}
\end{equation}
producing:
\begin{equation}\label{eq:c-fin}
\begin{split}
& \ff{c} \mapsto \llbracket \br
& \quad \ff{center} \mapsto \ff{point}(\ff{-3}, \ff{9}), \br
& \quad \ff{radius} \mapsto \ff{40}, \br
& \quad \varphi \mapsto \ff{center}, \br
& \quad \ff{is-inside}(\ff{p}) \mapsto \llbracket \br
& \quad \quad \varphi \mapsto \rho.\ff{distance}(\ff{p}).\ff{lte}(\ff{radius}) \br
& \quad \rrbracket \br
& \rrbracket.
\end{split}
\end{equation}
Because of decoration, the expression
\(\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}:
\begin{equation}\label{eq:is}
\begin{split}
& \ff{is} \mapsto \ff{c}.\ff{is-inside}(\ff{point}(\ff{1}, \ff{7})),
\end{split}
\end{equation}
producing:
\begin{equation}\label{eq:c-fin2}
\begin{split}
& \ff{c} \mapsto \llbracket \br
& \quad \ff{center} \mapsto \ff{point}(\ff{-3}, \ff{9}), \br
& \quad \ff{radius} \mapsto \ff{40}, \br
& \quad \varphi \mapsto \ff{center}, \br
& \quad \ff{is-inside} \mapsto \llbracket \br
& \quad \quad \ff{p} \mapsto \ff{point}(\ff{1}, \ff{7}), \br
& \quad \quad \varphi \mapsto \rho.\ff{distance}(\ff{p}).\ff{lte}(\ff{radius}) \br
& \quad \rrbracket \br
& \rrbracket.
\end{split}
\end{equation}
It is important to notice that attributes of a decoratee
don't belong to the scope of its decorator.
\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 void attribute.
\end{definition}
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.
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{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.
\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.
\end{definition}
For example, without any other objects in scope it is safe
to assume the following, however there is no guarantee that
the actual numbers will be the same in all implementations:
\begin{equation}
\begin{split}
& \ff{x}(\ff{y}) \mapsto \llbracket \rrbracket \br
& \ff{z} \mapsto \ff{x} ( \ff{y} \mapsto \ff{42} ) \br
& \Phi.\nu = 0, \ff{x}.\nu = 1, \ff{42}.\nu = 2, \ff{z}.\nu = 3.
\end{split}
\end{equation}

66
paper/sections/complexity.tex
View File

@ -1,66 +0,0 @@
One of the most critical factors affecting software maintainability is
its complexity. The design of a programming language may either
encourage programmers to write code with lower complexity, or
do the opposite and provoke the creation of code with higher
complexity. The following design patterns, also known as anti-patterns, increase complexity,
especially if being used by less experienced programmers
(most critical are at the top of the list):
\newcounter{pattern}
\newcommand{\pattern}[1]{\item P\refstepcounter{pattern}\thepattern\label{ptn:#1}: }
\newcommand{\solution}[1]{
\item \foreach \r [count=\i] in {#1} {%
\ifnum\i=1%
% nothing
\else%
, %
\fi%
P\ref{ptn:\r}%
} \(\to\)
}
\begin{itemize}
\pattern{return-null} Returning NULL references in case of error \\ \citep{hoare2009null}
\pattern{inheritance} Implementation inheritance (esp. multiple) \\ \citep{holub2003extends}
\pattern{mutable} Mutable objects with side-effects \\ \citep{bloch2016effective}
\pattern{casting} Type casting \\ \citep{mcconnell2004codecomplete, gannimo2017typeconfusion}
\pattern{utility} Utility classes with only static methods \\ \citep{eo1}
\pattern{reflection} Runtime reflection on types \\ \citep{eo1}
\pattern{setters} Setters to modify object's data \\ \citep{holub2004more}
\pattern{accept-null} Accepting NULL as function arguments \\ \citep{hoare2009null}
\pattern{global} Global variables and functions \\ \citep{mcconnell2004codecomplete}
\pattern{singleton} Singletons \\ \citep{nystrom2014game, eo1}
\pattern{factory} Factory methods instead of constructors \\ \citep{eo1}
\pattern{swallowing} Exception swallowing \\ \citep{rocha2018javaexception}
\pattern{getters} Getters to retrieve object's data \\ \citep{holub2004more}
\pattern{mixins} Code reuse via mixins (we can think of this as a special case of workaround for the lack of multiple inheritance) \\ \citep{mcconnell2004codecomplete}
\pattern{comments} Explanation of logic via comments \\ \citep{martin2008cleancode,mcconnell2004codecomplete}
\pattern{temporal} Temporal coupling between statements \\ \citep{eo1}
\pattern{formatting} Frivolous inconsistent code formatting \\ \citep{martin2008cleancode,mcconnell2004codecomplete}
\end{itemize}
In Java, C++, Ruby, Python, Smalltalk, JavaScript,
PHP, C\#, Eiffel, Kotlin, Erlang, and other languages most
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 \eolang{} by design:
\begin{itemize}
\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
\solution{casting,reflection} There are no types
\solution{global} There is no global scope
\solution{swallowing} There are no exceptions
\solution{mixins} There are no mixins
\solution{comments} Inline comments are prohibited
\solution{temporal} There are no statements
\solution{formatting} The syntax explicitly defines style
\end{itemize}
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.

171
paper/sections/features.tex
View File

@ -1,171 +0,0 @@
\newcounter{feature}
\renewcommand\thefeature{\thesection.\arabic{feature}}
\newcommand\feature[2]{{\refstepcounter{feature}\label{feature:#1}\textbf{%
%\thefeature.
#2%
}.\;}}
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
\cref{sec:calculus,sec:syntax}, but to compare \eolang{} with other
programming languages and informally identify similarities.
\feature{no-classes}{No Classes}
%
\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 \eolang{} such object alteration is not allowed.
\feature{no-types}{No Types}
%
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 \eolang{}.
\feature{no-inheritance}{No Inheritance}
%
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},
but only Kotlin~\citep{jemerov2017kotlin} has decorators
as a language feature. In all other languages, the Decorator pattern~\citep{gamma1994design}
has to be implemented manually~\citep{bettinibono2008delegation}.
\feature{no-methods}{No Methods}
%
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 \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++, \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 attached to attributes ``as is'' and can't be modified.
\feature{no-static}{No Static Entities}
%
Unlike Java and C\#,
\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 \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 \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 \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 \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 \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 \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.
\feature{no-empty}{No Empty Objects}
%
Unlike Java, C++ and all other OO languages,
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.
\feature{no-private}{No Private Attributes}
%
Similar to Python~\citep{lutz2013learning} and Smalltalk~\citep{hunt1997smalltalk},
\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
hiding can anyway easily be violated via getters, and usually is, making the code longer
and less readable, as explained by~\citet{holub2004more}.
\feature{no-global}{No Global Scope}
%
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 \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
don't mean constants though. While the latter will
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}
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.
%
There are number of OOP languages that also prioritize immutability of objects.
In Rust~\citep{matsakis2014rust}, for example, all variables are immutable by
default, but can be made mutable via the \ff{mut} modifier. Similarly,
D~\citep{bright2020origins} has qualifier \ff{immutable}, which expresses
transitive immutability of data.
\feature{no-exceptions}{No Exceptions}
%
In most OO languages exception handling~\citep{goodenough1975exception}:
happens through an imperative error-throwing statement.
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 \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 \eolang{} would only have bodies and no other attributes,
they would be functions. It is legit to
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 \eolang{} are not new concepts, but lower-level
objects.
\feature{no-mixins}{No mixins}
%
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.

222
paper/sections/four.tex
View File

@ -1,222 +0,0 @@
In order to answer the question, whether
the proposed object calculus is sufficient
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.
\subsection{Abstraction}
Abstraction, which is called ``modularity'' by~\citet{grady2007object}, is,
according to~\citet[p.203]{west2004object},
``the act of separating characteristics into the relevant and
irrelevant to facilitate focusing on the relevant without
distraction or undue complexity.'' While \citet{stroustrup1997} suggests
C++ classes as instruments of abstraction, the ultimate goal
of abstraction is decomposition, according to~\citet[p.73]{west2004object}:
``composition is accomplished by applying abstraction---the
`knife' used to carve our domain into discrete objects.''
In \phic{} objects are the elements the problem domain
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
``a relationship among classes wherein one class shares the structure
and/or behavior defined in one (single inheritance)
or more (multiple inheritance) other classes,'' where
``a subclass typically augments or
restricts the existing structure and behavior of its superclasses.''
The purpose of inheritance, according to~\citet{meyer1997object}, is
``to control the resulting potential complexity'' of the design
by enabling code reuse.
Consider a classic case of behaviour extension, suggested by~\citet[p.38]{stroustrup1997}
to illustrate inheritance. C++ class \ff{Shape} represents a graphic object
on the canvas (a simplified version of the original code):
\begin{ffcode}
class Shape {
Point center;
public:
void move(Point to) { center = to; draw(); }
virtual void draw() = 0;
};
\end{ffcode}
The method \ff{draw()} is ``virtual,'' meaning that it is not implemented in the class
\ff{Shape} but may be implemented in sub-classes, for example in
the class \ff{Circle}:
\begin{ffcode}
class Circle : public Shape {
int radius;
public:
void draw() { /* To draw a circle */ }
};
\end{ffcode}
The class \ff{Circle} inherits the behavior of the class \ff{Shape} and
extends it with its own feature in the method \ff{draw()}. Now, when the
method \ff{Circle.move()} is called, its implementation from the class \ff{Shape}
will call the virtual method \ff{Shape.draw()}, and the call will be dispatched
to the overridden method \ff{Circle.draw()} through the ``virtual table'' in the class \ff{Shape}.
The creator of the class \ff{Shape} is now aware of sub-classes
which may be created long after, for example \ff{Triangle}, \ff{Rectangle}, and so on.
Even though implementation inheritance and method overriding seem to
be powerful mechanisms, they have been criticized.
According to~\citet{holub2003extends}, the main problem with
implementation inheritance is that it introduces unnecessary coupling
in the form of the ``fragile base class problem,''
as was also formally demonstrated by~\citet{mikhajlov1998study}.
The fragile base class problem is one of the reasons why
there is no implementation inheritance in \phic{}.
Nevertheless, object hierarchies to enable code reuse
in \phic{} may be created using decorators.
This mechanism is also known as ``delegation'' and, according
to~\citet[p.98]{grady2007object}, is ``an alternate approach to inheritance, in which
objects delegate their behavior to related objects.''
As noted by~\citet[p.139]{west2004object}, delegation is ``a way to extend or restrict
the behavior of objects by composition rather than by inheritance.''
\citet{seiter1998evolution} said that ``inheritance breaks encapsulation'' and suggested that
delegation, which they called ``dynamic inheritance,'' is a better way
to add behavior to an object, but not to override existing behavior.
The absence of inheritance mechanism in \phic{} doesn't make it
any weaker, since object hierarchies are available. \citet{grady2007object}
while naming four fundamental elements of object model mentioned
``abstraction, encapsulation, modularity, and hierarchy'' (instead of inheritance, like
some other authors).
\subsection{Polymorphism}
According to~\citet[p.467]{meyer1997object}, polymorphism means
``the ability to take several forms,'' specifically a variable
``at run time having the ability to become attached to objects
of different types, all controlled by the static declaration.''
\citet[p.67]{grady2007object} explains polymorphism as
an ability of a single name (such as a variable declaration)
``to denote objects of many different classes that are related by some common superclass,''
and calls it ``the most powerful feature of object-oriented programming languages.''
Consider an example C++ class, which is used by~\citet[p.310]{stroustrup1997}
to demonstrate polymorphism (the original code was simplified):
\begin{ffcode}
class Employee {
string name;
public:
Employee(const string& name);
virtual void print() { cout << name; };
};
\end{ffcode}
Then, a sub-class of \ff{Employee} is created, overriding
the method \ff{print()} with its own implementation:
\begin{ffcode}
class Manager : public Employee {
int level;
public:
Employee(int lvl) :
Employee(name), level(lvl);
void print() {
Employee::print();
cout << lvl;
};
};
\end{ffcode}
Now, it is possible to define a function, which accepts a set
of instances of class \ff{Employee} and prints them one by one,
calling their method \ff{print()}.:
\begin{ffcode}
void print_list(set<Employee*> &emps) {
for (set<Employee*>::const_iterator p =
emps.begin(); p != emps.end(); ++p) {
(*p)->print();
}
}
\end{ffcode}
The information of whether elements of the set \ff{emps} are instances of \ff{Employee}
or \ff{Manager} is not available for the \ff{print\char`\_list} function in compile-time.
As explained by \citet[p.103]{grady2007object},
``polymorphism and late binding go hand in hand;
in the presence of polymorphism, the binding of a method
to a name is not determined until execution.''
Even though there are no explicitly defined types in \phic{},
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 \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.
Having this information in compile-time it is possible to guarantee
strong compliance of all objects and their users. To our knowledge,
this feature is not available in any other OOP languages.
\subsection{Encapsulation}
Encapsulation is considered the most important principle of OOP
and, according to~\citet[p.51]{grady2007object},
``is most often achieved through information hiding,
which is the process of hiding all the secrets of an object
that do not contribute to its essential characteristics;
typically, the structure of an object is hidden, as well
as the implementation of its methods.'' Encapsulation in C++ and
Java is achieved through access modifiers like \ff{public} or
\ff{protected}, while in some other languages, like JavaScript or Python,
there are no mechanisms of enforcing information hiding.
However, even though~\citet[p.51]{grady2007object} believe that
``encapsulation provides explicit barriers among different
abstractions and thus leads to a clear separation of concerns,''
in reality the barriers are not so explicit: they can be easily
violated.
\citet[p.141]{west2004object} noted that
``in most ways, encapsulation is a discipline more than a real barrier;
seldom is the integrity of an object protected in any absolute
sense, and this is especially true of software objects,
so it is up to the user of an object to respect that object's encapsulation.''
There are even programming ``best practices,'' which encourage
programmers to compromise encapsulation: getters and setters are
the most notable example, as was demonstrated by~\citet{holub2004more}.
The inability to make the encapsulation barrier explicit
is one of the main reasons why there is no information hiding in \phic{}.
Instead, all attributes of all objects in \phic{}
are visible to any other object.
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 \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.
For example, the object \ff{garage} is referring to the object
\ff{car.engine.size}. This means that the depth of this connection between objects
\ff{garage} and \ff{car} is two, because the object \ff{garage} is using
two dots to access the object \ff{size}. Then, all collected depths from
all object connections are analyzes and the build is rejected if the numbers
are higher than a predefined threshold. How exactly the numbers are analyzed
and what are the possible values of the threshold is a subject for future
researches.

118
paper/sections/intro.tex
View File

@ -1,118 +0,0 @@
It is difficult to define what exactly is OOP, as
``the term has been used to mean different things,'' according to~\citet{stefik1985object}.
\citet{madsen1988object} claimed that ``there are as many
definitions of OOP as there papers and books on the topic.''
\citet{armstrong2006quarks} made a noticeable observation: ``When
reviewing the body of work on OO development, most authors simply suggest a set
of concepts that characterize OO, and move on with their research or discussion.
Thus, they are either taking for granted that the concepts are known or implicitly
acknowledging that a universal set of concepts does not exist.''
\subsection{Lack of Formal Model}
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
it (differently). And no one will know just what it is.''
There is a fundamental problem in OOP---the lack of a rigorous formal model,
as was recapped by~\citet{eden2001principles}: ``Unfortunately, architectural
\nospell{formalisms} have largely ignored the OO idiosyncrasies. Few works recognized the
elementary building blocks of design and architecture patterns.
As a result of this oversight, any attempt to use \nospell{formalisms} for the specification of OO
architectures is destined to neglect key regularities in their organization.''
There is no uniformity or an agreement on the set of features and mechanisms
that belong in an OO language as ``the paradigm itself is far too general,'' as was
concluded by~\citet{nierstrasz1989survey} in his survey.
OO and semi-OO programming languages treat OOP differently and have variety of
different features to follow the concept of \nospell{object-orientedness}. For
example, Java has classes and types (interfaces) but doesn't
have multiple inheritance~\citep{alpern2001efficient},
C++ has multiple inheritance but doesn't directly support mixins~\citep{burton2014using},
Ruby and PHP don't have generics and types, but have traits~\citep{bi2018typed},
JavaScript doesn't have classes, but has prototypes~\citep{richards2010analysis}, and so on.
It was noted by \citet{danforth1988type} that
object-oriented programming, like functional programming or logic programming,
incorporates a metaphor in which computation is viewed in terms divorced from the
details of actual computation. However, in the case of OOP, this metaphor is rarely introduced
with the mathematical precision available to the functional or logic programming
models. Rather, OOP is generally expressed in philosophical terms,
resulting in a natural proliferation of opinions concerning
exactly what OOP really is.
\subsection{Complaints of Programmers}
Although the history of OOP goes back for more than
50 years to the development of Simula~\citep{dahl1966simula}, OOP is under heavy
criticism since the beginning to nowadays, mostly for its inability
to solve the problem of software complexity.
According to~\citet{graham2004hackers}, ``somehow the idea of reusability
got attached to OOP in the 1980s, and no amount of evidence to the contrary
seems to be able to shake it free,'' while
``OOP offers a sustainable way to write spaghetti code.''
\citet{west2004object} argues that the contemporary mainstream understanding
of objects (which is not behavioral) is ``but a pale shadow of the original idea'' and
``anti-ethical to the original intent.''
\citet{gosling1995java} notes that
``unfortunately, `object oriented' remains misunderstood and
over-marketed as the silver bullet that will solve all our software ills.''
\subsection{High Complexity}
\citet{nierstrasz2010ten} said that ``OOP is about taming
complexity through modeling, but we have not mastered this yet.''
Readability and complexity issues of OO code remain unsolved till
today. \citet{shelly2015flaws} claimed that ``Reading an OO
code you can't see the big picture and it is often impossible to review all the
small functions that call the one function that you modified.''
\citet{khanam2018} in a like manner affirmed: ``Object oriented programming
promotes ease in designing reusable software but the long coded methods makes
it unreadable and enhances the complexity of the methods.''
The complexity of OO software is higher than the industry would expect, taking
into account the amount of efforts invested into the development of
OO languages. As was concluded by~\citet{bosch1997object}, ``OO frameworks have
number of problems that complicate development, usage, composition and
maintenance of software.''
For example, the infamous legacy code has its additional overhead associated with OO
languages---inheritance mechanism, which ``allows you to write less code
at the cost of less readability,'' as explained by~\citet{carter1997oopvsr}.
It is not infrequently when ``inheritance is overused and misused,''
which leads to ``increased complexity of the code and its maintenance,''
as noted by~\citet{bernstein2016legacy}.
The lack of formalism encouraged OOP language creators to
invent and implement language features, often known as ``syntax sugar,''
which are convenient for some of them in some special cases but
jeopardize the consistency of design when being used too often
and by less mature programmers. The most obvious
outcome of design inconsistencies is high complexity due to low readability,
which negatively affects the quality and leads to functionality defects.
\subsection{Solution Proposed}
\eolang{}\footnote{\url{https://www.eolang.org}}
was created in order to eliminate the problem of complexity of
OOP code, providing
\begin{inparaenum}[1)]
\item a formal object calculus and
\item a programming language with a reduced set of features.
\end{inparaenum}
The proposed \phic{} represents an object model through
data and objects, while operations with them are possible
through formation, application, and decoration. The calculus
introduces a formal apparatus for manipulations with objects.
\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, \eolang{} enables four key principles of OOP:
abstraction, inheritance, polymorphism, and encapsulation.

31
paper/sections/overview.tex
View File

@ -1,31 +0,0 @@
The following four principles stay behind the
apparatus we introduce:
\begin{itemize}
\item An \emph{object} is a collection of \emph{attributes},
which are uniquely named bindings to objects. An object
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{void}---isn't \emph{attached} to any object. An object
is \emph{closed} otherwise.
\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 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 attached attributes of its decoratee.
\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 attached to.
The dataization of an object at the highest level of composition
leads to the execution of a program.
\end{itemize}

42
paper/sections/pragmatics.tex
View File

@ -1,42 +0,0 @@
First, the source code of \eolang{} is parsed by ANTLR4-powered
parser and an intermediate representation is built in XML,
as was demonstrated in \cref{sec:xml}.
The output format is called \xmir{}.
One \ff{.eo} file with
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 \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{<o/>},
referring it to the line inside XML document, where the object \ff{r} is defined:
\begin{ffcode}
<o name="circle">
<o name="r"/> (*@\label{ln:xml-circle2-r}@*) <!-- (*@\texttt{\lref{xml-circle2-r}}@*) -->
<o base=".times" name="square">
<o base="r" (*@\textbf{\texttt{ref="\lref{xml-circle2-r}"}}@*)/>
<o base="int" data="int">2</o>
<o base="float" data="float">3.14</o>
</o>
</o>
\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
be added to the pipeline for example in order to detect inconsistencies
in \xmir{}, enforce new semantic rules, or optimize object structures.
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
\ff{java.util.HashMap} instances.
Then, Java source code is compiled to bytecode by OpenJDK Java compiler.
Then, runtime dependencies with atoms are taken from Maven Central
and placed to the Java classpath.
Finally, JRE runs the program through \ff{Main.java} class together with
all \ff{.jar} dependencies in the classpath.

56
paper/sections/related.tex
View File

@ -1,56 +0,0 @@
Attempts were made to formalize OOP and introduce object calculus,
similar to lambda calculus~\citep{barendregt2012} used in functional programming.
For example, \citet{abadi1995imperative} suggested an imperative calculus of objects,
which was extended by~\citet{bono1998imperative} to support classes,
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
introduce object calculus for asynchronous communication, which was further
referenced by~\citet{jones1993pi} in their work on object-based design notation.
A few attempts were made to reduce existing OOP languages
and formalize what is left. Featherweight Java is the most notable example
proposed by~\citet{igarashi2001featherweight}, which is
omitting almost all features of the full language (including interfaces and
even assignment) to obtain a small calculus.
Later it was extended by~\citet{jagannathan2005transactional} to support
nested and multi-threaded transactions. Featherweight Java is used in formal languages
such Obsidian~\citep{coblenz2019} and SJF~\citep{usov2020}.
Another example is Larch/C++~\citep{cheon1994quick}, which is a formal
algebraic interface
specification language tailored to C++. It allows interfaces of C++ classes and
functions to be documented in a way that is unambiguous and concise.
Several attempts to formalize OOP were made by extensions of the most popular
formal notations and methods, such as Object-Z~\citep{duke1991object} and
VDM++~\citep{durr1992vdm}. In
Object-Z, state and operation schemes are encapsulated into classes. The formal
model is based upon the idea of a class history~\citep{duke1990towards}.
Although, all these OO extensions do not have comprehensive
refinement rules that can be used to transform specifications into implemented
code in an actual OO programming language, as was noted by~\citet{paige1999object}.
\citet{bancilhon1985calculus} suggested an object calculus as an extension
to relational calculus. \citet{jankowska2003anotheroop} further developed
these ideas and related them to a Boolean algebra.
\citet{leekwakryu1996transform} developed an algorithm
to transform an object calculus into an object algebra.
However, all these theoretical attempts to formalize OO languages
were not able to fully describe their features, as was noted
by~\citet{nierstrasz1991towards}:
``The development of concurrent object-based programming languages
has suffered from the lack of any generally accepted formal
foundations for defining their semantics.'' In addition, when describing the
attempts of formalization, \citet{eden2002visual} summarized: ``Not one of the
notations is defined formally, nor provided with
\nospell{denotational} semantics,
nor founded on axiomatic semantics.''
%
Moreover, despite these efforts,
\citet{ciaffaglione2003reasoning,ciaffaglione2003typetheories,ciaffaglione2007theory_of_contexts}
noted in their series of works that a relatively little formal work has
been carried out on object-based languages and it remains true to this day.

629
paper/sections/semantics.tex
View File

@ -1,629 +0,0 @@
In order to explain how declarative expressions of \phic{} can
be translated into imperative instructions of a target computing platform, we
\begin{inparaenum}[1)]
\item represent object model as \emph{object graph},
\item introduce a set of \emph{graph modifying instructions} (SODG),
\item define \emph{transformation rules} between \phic{} expressions and SODGs,
\item suggest \emph{dataization algorithm} turning object graph into function composition.
\end{inparaenum}
\subsection{Object Graph}\label{ssec:graph}
Consider the object from \lrefs{book2}{book2-end},
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\)};
\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\)};
\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 (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\)};
\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 [anchor=south east] at (current bounding box.south east) {
\begin{minipage}{15em}\raggedleft
\(d_{4} \to \ff{"Object Thinking"}\)
\end{minipage}};
\end{phigure}
\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 \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 \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{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.
\subsection{SODG}
In order to formalize the process of drawing an object graph,
we introduced a few SODGs:
\makeatletter\newlength\tdima
\newcommand\tabfill[1]{%
\setlength\tdima{\linewidth}%
\addtolength\tdima{\@totalleftmargin}%
\addtolength\tdima{-\dimen\@curtab}%
\parbox[t]{\tdima}{\raggedright#1\ifhmode\strut\fi}}
\makeatother
\begin{tabbing}
\hspace*{2.6cm}\= \kill
\(\ff{ADD}(v_1)\)
\>
\tabfill{Adds a new vertice \(v_1\) to the graph:}
\\
\>
\begin{phigure}
\node[object] (v1) {\(v_1\)};
\end{phigure}
\\
\(\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:}
\\
\> \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\)};
\end{phigure}
\\
\(\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},
and
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[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\)};
\draw (v3) -- (v2d) node [attr] {\ff{t}};
\end{phigure}
\\
\(\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\):}
\\
\> \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[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\)};
\end{phigure}
\\
\(\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\):}
\\
\> \begin{phigure}
\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\)};
\end{phigure}
\\
\(\ff{DATA}(v_1, \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[transforms, right=0.3cm of v1] {};
\node[data, right=1cm of v1] (v1d) {\(\Gamma\)};
\end{phigure}
\\
\(\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):}
\\
\> \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\)};
\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 \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\)@*));
\end{ffcode}
\end{twocols}
\subsection{Transformation Rules}
In order to formalize the mechanism of turning \phic{} formulas into an object graph,
we introduced a number of transformation rules. \rrule{abstract} explains how
an abstract object gets transformed to a sequence of SODGs:
\begin{equation*}
\dfrac
{v_i | x(a_1, a_2, \dots, a_n) \mapsto \llbracket E \rrbracket}
{\begin{matrix}
\ff{ADD}(v_{i\rr x}) \quad \ff{BIND}(v_i, v_{i\rr x}, x) \\
\forall j \in [1; n] \left( \ff{ADD}(v_{i\rr x\rr j}) \quad \ff{BIND}(v_{i\rr x}, v_{i\rr x\rr j}, a_j) \right) \\
v_{i\rr x}|E
\end{matrix}}
\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 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
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{}.
For the sake of simplicity of the graphs, the hierarchical notation won't be
used in practical examples below. Instead, single integer indexes will
be used to denote vertices and edges, being incremented sequentially
in order to avoid duplication.
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}
{\begin{matrix}
\ff{ADD}(v_{12}) \quad \ff{BIND}(v_5, v_{12}, \ff{is-inside}) \\
\ff{ADD}(v_{13}) \quad \ff{BIND}(v_{12}, v_{13}, \ff{p}) \\
v_{12}|\varphi \mapsto \dots
\end{matrix}}
\end{equation*}
The effect of all SODGs generated by this rule would be the following
on an object graph:
\begin{center}\begin{phigure}
\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}\)};
\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}\)};
\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}\).
\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):
\begin{equation*}
\dfrac
{v_i | E_1,E_2,\dots,E_n}
{v_i | E_1 \quad v_i|E_2 \quad \dots \quad v_i|E_n}
\jrule{comma}
\end{equation*}
\rrule{attribute} turns an attribute into an edge on the graph
and then continues processing the expression that goes after the
object being referred, by looking at the created edge:
\begin{equation*}
\dfrac
{v_i | a \mapsto x \; E}
{\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
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\)
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,
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
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,
providing other rules the opportunity to deal with it.
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:
\begin{equation*}
\dfrac
{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}
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
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):
\begin{center}\begin{phigure}
\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}\)};
\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);
\end{phigure}\end{center}
The dot notation is resolved by \rrule{dot}, which unlike previously
seen rules, deals with an edge instead of a vertice:
\begin{equation*}
\dfrac
{e_i | .x \; E}
{\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
else, the tail of the expression. In this example, the instance
of the rule would look like this:
\begin{equation*}
\dfrac
{e_{14} | \ohat{.x}{.\ff{distance}} \; \ohat{E}{(\ff{p}).\ff{lte}(\ff{radius})}}
{\ff{DOT}(e_{14}, \ff{distance}, v_{15}, e_{16}) \quad e_{16}|(\ff{p}).\ff{lte}(\ff{radius})}
\end{equation*}
Visually, the execution of this rule would lead to the following
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}\)};
\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);
\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}\)};
\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}\)};
\draw (v15) -- (v5d) node [attr] {\ff{t}};
\end{phigure}\end{center}
The application of arguments to abstract objects is transformed
to the object graph by \rrule{copy}, which also deals
with an edge instead of a vertice:
\begin{equation*}
\dfrac
{e_i | (E_1) \; E_2}
{\ff{COPY}(e_i, v_{i\rr 1}, e_{i\rr 2}) \quad v_{i\rr 1}|E_1 \quad e_{i}|E_2}
\jrule{copy}
\end{equation*}
To continue the processing of the expression inside the abstract object
\ff{is-inside} the rule may be applied as the following:
\begin{equation*}
\dfrac
{e_{16} | \ohat{E_1}{(\ff{to} \mapsto \xi.\ff{p})} \; \ohat{E_2}{.\ff{lte}(\ff{radius})}}
{\ff{COPY}(e_{16}, v_{17}, e_{18}) \quad v_{17}|\ff{to} \mapsto \xi.\ff{p} \quad e_{16}|.\ff{lte}(\ff{radius})}
\end{equation*}
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[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);
\end{phigure}\end{center}
The last rule deals with data, such as integers, string literals, and so on
(together referred to as \(\Gamma\)):
\begin{equation*}
\dfrac
{v_i | \Gamma}
{\ff{ADD}(d_i) \quad \ff{BIND}(v_i,d_i,\Delta) \quad \ff{DATA}(d_i, \Gamma)}
\jrule{data}
\end{equation*}
There is also one rule, which transforms atoms to the object graph by \rrule{lambda}
attaching lambda expressions to vertices:
\begin{equation*}
\dfrac
{v | \lambda s . M}
{\ff{ATOM}(v, M)}
\jrule{lambda}
\end{equation*}
Visually, the rule would produce the following modifications on the graph
for \cref{def:stdout}:
\begin{center}\begin{phigure}
\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}\)};
\draw (phi-d) -- (v1d) node [attr] {\ff{stdout}};
\end{phigure}\end{center}
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 \cref{eq:is}.
\subsection{Dataization}
We define ``dataization'' as a process of turning an object into data,
which said object \emph{represents}. For example, the object at
\lref{sum-instance} represents an algebraic sum of three integers.
The process of dataization expects each object to know what data
it represents and if it doesn't know it, the object must know
where to get the data. The object \ff{sum} is not data, but
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
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\)};
\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}\)};
\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[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\)};
\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\)};
\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\)};
\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\).
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\):
\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)\) \\
\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\) \\
\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
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\).
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.
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.
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{end}
\end{algo}
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\).
\begin{figure*}
\resizebox{.75\textwidth}{!}{
\begin{phigure}
\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\)};
\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\)};
\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\)};
\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\)};
\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\)};
\draw[rho] (v5) -- (v4d1);
\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[rho] (v7) -- (v5d1);
\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[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}\)};
\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}\)};
\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}\)};
\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}\)};
\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\)};
\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}\)};
\draw[parent] (v10) -- (v1d1);
\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 (v10) -- pic[sloped,rho]{parallel arrow={0.3,-0.15}} (v11) node [attr] {\ff{center}};
\node[dup] (v15d1) [left=1cm of v11] {\(v_{15}\)};
\draw[parent] (v11) -- (v15d1);
\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 (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\)};
\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}\)};
\draw[parent] (v12) -- (v1d2);
\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}\)};
\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}\)};
\draw[parent] (v13) -- (v15d2);
\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 (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\)};
\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)\) \\
\end{minipage}};
\end{phigure}}
\figcap{The graph of the object \ff{is} from \cref{eq:is}.}
\label{fig:is}
\end{figure*}

590
paper/sections/syntax.tex
View File

@ -1,590 +0,0 @@
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 \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 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 \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
\begin{CJK}{UTF8}{gbsn}
\ff{i文件}
\end{CJK}
are valid identifiers.
Identifiers are case-sentitive: \ff{car} and \ff{Car} are two different identifiers.
Java-notation is used for numbers and strings.
\subsection{Identity, State, and Behavior}
According to~\citet{grady2007object}, an object in OOP has state, behavior, and identity:
``The state of an object encompasses all of the properties of
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 \eolang{} makes a difference between these three categories.
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}@*)
\end{ffcode}
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}
book "978-1519166913" > b1
\end{ffcode}
Here, \ff{b1} is a new object created.
Its only attribute is accessible as \ff{b1.isbn}.
A similar \emph{abstract} object, but with two new \emph{state} attributes, would
look like:
\begin{ffcode}
[isbn] > book2 (*@\label{ln:book2}@*)
"Object Thinking" > title
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 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}@*)
"Object Thinking" > title
memory 0 > price
[p] > set-price
^.price.write p > @ (*@\label{ln:book3-end}@*)
\end{ffcode}
The price of the book may be changed with this one-liner:
\begin{ffcode}
book3.set-price 19.99
\end{ffcode}
\subsection{Indentation}
This is an example of an abstract object \ff{vector}, where
spaces are replaced with the ``\textvisiblespace'' symbol in order to demonstrate
the importance of their presence in specific quantity
(for example, there has to be exactly one space after the closing square bracket at the
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}@*)
plus.
dx.times dx
dy.timex dy (*@\label{ln:length-end}@*) (*@\label{ln:vector-end}@*)
\end{ffcode}
}
The code at \lref{comment} is a \emph{comment}.
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
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}
can be written in one line, using \emph{dot notation}:
\begin{ffcode}
((dx.times dx).plus (dy.timex dy)).sqrt > length
\end{ffcode}
An \emph{inverse} dot notation is used in order to simplify
the syntax. The identifier that goes after the dot is written
first, the dot follows, and the next line contains the part
that is supposed to stay before the dot. It is also possible to rewrite
this expression in multiple lines without the usage of
inverse notation, but it will look less readable:
\begin{ffcode}
dx.times dx (*@\label{ln:dx-pow}@*)
.plus
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
a new argument \ff{dx}. Then, the next line is the object \ff{plus} taken
from the object created at the first line, using the dot notation. Then,
\lref{dx-pow-2} is the argument passed to the object \ff{plus}.
The code at \lref{dx-pow-3} takes the object \ff{sqrt} from the object constructed
at the previous line, and gives it the name \ff{length}.
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 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 void attribute \ff{x} and two attached attributes \ff{succ} and \ff{prev}:
\begin{ffcode}
[x]
x.plus 1 > succ
x.minus 1 > prev
\end{ffcode}
The arguments of \ff{plus} and \ff{minus} are provided in a \emph{horizontal}
mode, without the use of indentation. It is possible to rewrite this code
in a \emph{vertical} mode, where indentation will be required:
\begin{ffcode}
[x] (*@\label{ln:succ}@*)
x.plus > succ
1
x.minus > prev
1 (*@\label{ln:succ-end}@*)
\end{ffcode}
This abstract object can also be written in a horizontal mode,
because it is anonymous:
\begin{ffcode}
[x] (x.plus 1 > succ) (x.minus 1 > prev)
\end{ffcode}
\subsection{\eolang{} to XML}\label{sec:xml}
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:
\begin{ffcode}
<o name="vector">
<o name="dx"/>
<o name="dy"/>
<o name="length" base=".sqrt">
<o base=".plus">
<o base=".times">
<o base="dx"/>
<o base="dx"/>
</o>
<o base=".times">
<o base="dy"/>
<o base="dy"/>
</o>
</o>
</o>
</o>
\end{ffcode}
Each object is represented by an \ff{<o/>} 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 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}
There are a few abstract objects which can't be directly copied, such as
\ff{float} and \ff{int}. They are created by the compiler when it meets
a special syntax for data, for example:
\begin{ffcode}
[r] > circle
r.times 3.14 > circumference
\end{ffcode}
This syntax would be translated to XMIR (XML based data format):
\begin{ffcode}
<o name="circle"> (*@\label{ln:xml-circle}@*)
<o name="r"/>
<o base=".times" name="circumference">
<o base="r"/> (*@\label{ln:xml-circle-r}@*)
<o base="float">
<o base="bytes">40-09-1E-B8-51-EB-85-1F</o>
</o>
</o>
</o> (*@\label{ln:xml-circle-end}@*)
\end{ffcode}
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}
\toprule
Data & Example & Size \\
\midrule
\ff{bytes} & \ff{1F-E5-77-A6} & 4 \\
\ff{string} & \ff{"Hello, \foreignlanguage{russian}{друг}!"} & 16 \\
& \ff{"\textbackslash{}u5BB6"} or \begin{CJK}{UTF8}{gbsn}\ff{"家"}\end{CJK} & 2 \\
\ff{int} & \ff{1024}, \ff{0x1A7E}, or \ff{-42} & 8 \\
\ff{float} & \ff{3.1415926} or \ff{2.4e-34} & 8 \\
\ff{bool} & \ff{TRUE} or \ff{FALSE} & 1 \\
\bottomrule
\end{tabularx}
\figcap{The syntax of all data with examples. The ``Size'' column
denotes the number of bytes in the \ff{as-bytes} attribute.
UTF-8 is the encoding used in \ff{string} object.}
\label{tab:types}
\end{table}
The \ff{tuple} is yet another data, which can't be copied
directly. There is a special syntax for making tuples,
which looks similar to object copying:
\begin{ffcode}
* "Lucy" "Jeff" 3.14 (*@\label{ln:tuple-1}@*)
* > a (*@\label{ln:tuple-2a}@*)
(* "a")
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
and one float. The code at \lrefs{tuple-2a}{tuple-2b} makes a tuple named \ff{a} with another
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{Scope Brackets}
Brackets can be used to group object arguments in horizontal mode:
\begin{ffcode}
sum (div 45 5) 10 (*@\label{ln:sum}@*)
\end{ffcode}
The \ff{(div 45 5)} is a copy of the abstract object \ff{div}
with two arguments \ff{45} and \ff{5}. This object is itself
the first argument of the copy of the object \ff{sum}. Its second
argument is \ff{10}. Without brackets the syntax would read differently:
\begin{ffcode}
sum div 45 5 10
\end{ffcode}
This expression denotes a copy of \ff{sum} with four arguments.
\subsection{Inner Objects}
An abstract object may have other abstract objects as its attributes,
for example:
\begin{ffcode}
# A point on a 2D canvas
[x y] > point
[to] > distance
length. > len (*@\label{ln:vector-length}@*)
vector
to.x.minus (^.x)
to.y.minus (^.y)
\end{ffcode}
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}@*)
point
5:x
-3:y
point:to
13:x
3.9:y
\end{ffcode}
The parent object is \ff{(point 5 -3)}, while the object \ff{(point 13 3.9)}
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 void attribute to be attached to the
provided argument.
\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}@*)
[p] > is-inside
lte. > @
^.@.distance $.p (*@\label{ln:circle-phi-2}@*)
^.radius (*@\label{ln:circle-end}@*)
\end{ffcode}
The object \ff{circle} has a special attribute \ff{@}
at \lref{circle-phi}, which denotes
the \emph{decoratee}: an object to be extended,
also referred to as ``component'' by~\citet{gamma1994design}.
The \emph{decorator} \ff{circle}
has the same attributes as its decoratee \ff{center}, but also
its own attribute \ff{is-inside}. The attribute \ff{@} may be used
the same way as other attributes, including in dot notation, as it is done
at \lref{circle-phi-2}. However, this line
may be re-written in a more compact way, omitting the explicit
reference to the \ff{@} attribute, because all attributes
of the \ff{center} are present in the \ff{circle};
and omitting the reference to \ff{\$} because the default scope of visibility of
\ff{p} is the object \ff{is-inside}:
\begin{ffcode}
^.distance p
\end{ffcode}
The inner object \ff{is-inside} also has the \ff{@} attribute: it
decorates the object \ff{lte} (stands for ``less than equal'').
The expression at \lref{circle-phi-2} means:
take the parent object of \ff{is-inside},
take the attribute \ff{@} from it, then take the inner object \ff{distance}
from there, and then make a copy of it with the attribute \ff{p}
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\):
\begin{ffcode}
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 void, similar to other void
attributes, specifying it in the list of void attributes in
square brackets.
\subsection{Anonymous Formations}
A formation may be used as an argument of another object while
making a copy of it, for example:
\begin{ffcode}
(dir "/tmp").walk
*
[f]
f.is-dir > @
\end{ffcode}
Here the object \ff{walk} is copied with a single argument:
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 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 formation may be inlined
(the tuple is also inlined):
\begin{ffcode}
(dir "/tmp").walk
* ([f] (f.is-dir > @))
\end{ffcode}
An anonymous formation may have multiple attributes:
\begin{ffcode}
[x] (x.plus 1 > succ) (x.minus 1 > prev)
\end{ffcode}
This object has two attributes \ff{succ} and \ff{prev}, and doesn't
have a name.
The parent of each copy of the abstract object will be set by
the object \ff{walk} and will point to the \ff{walk} object itself.
\subsection{Constants}
\eolang{} is a declarative language with lazy evaluations. This means
that this code would read the input stream two times:
\begin{ffcode}
[] > hello
stdout > say
sprintf
"The length of %s is %d"
stdin.next-line > x!
x.length
\end{ffcode}
The \ff{sprintf} object will go to the \ff{x} two times. First time,
in order to use it as a substitute for \ff{\%s} and the second time for
\ff{\%d}. There will be two round-trips to the standard input stream, which
obviously is not correct. The exclamation mark at the \ff{x!} solves the
problem, making the object by the name \ff{x} a \emph{constant}. This means
that all attributes of \ff{x} are \emph{cached}. Important to notice
that the cache is \emph{not deep}: the attributes of attributes are not cached.
Here, \ff{x} is an attribute of the object \ff{hello}, even though
it is not defined as explicitly as \ff{say}. Anywhere a new
name shows up after the \ff{>} symbol, it is a declaration of a new
attribute in the nearest object abstraction.
\subsection{Explicit Shallow Copies}
There may be a need to make a copy of an object without giving any
parameters to it. This may be done with an apostrophe suffix:
\begin{ffcode}
point' > p
p 3 5 > p1
\end{ffcode}
Here, two objects will be created, \ff{p} and \ff{p1}, where
the former is an abstract one, a copy of \ff{copy}, while the
later is a closed one with two parameters specified. The
apostrophe suffix may be used anywhere after the name of an object,
for example:
\begin{ffcode}
circle
point' 3 a'
\end{ffcode}
Making a copy of \ff{circle} will not lead to making a copy of \ff{point},
which is encapsulated by \ff{circle}.
\subsection{Object Identity}
Each object has a special attribute \ff{<}, which is an integer
refering to a unique identifier of an object in the entire
runtime scope of a program. All of the following expressions are true:
\begin{ffcode}
TRUE.<.eq (TRUE.<)
42.<.eq (42.<)
point.<.eq (point.<)
\end{ffcode}
All of the following expressions are false:
\begin{ffcode}
42.<.eq (7.<)
(2.plus 2).<.eq (4.<)
(point 3 5).<.eq ((point 3 5).<)
(* 1 2).<.eq ((* 1 2).<)
\end{ffcode}
\subsection{Metas and License}
A program may have a comment at the beginning of the file, which
is called a \emph{license}. The license may be followed by an optional
list of \emph{meta} statements, which are passed to the compiler
as is. The meaning of them depends on the compiler and may vary
between target platforms. This program instructs the compiler
to put all objects from the file into the package \ff{org.example}
and helps it resolve the name \ff{stdout}, which is external
to the file:
\begin{ffcode}
# (c) John Doe, 2021
# All rights reserved.
# The license is MIT
+package org.example
+alias org.eolang.io.stdout
[args] > app
stdout > @
"Hello, world!\n"
\end{ffcode}
\subsection{Atoms}
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},
which is an atom. Its implementation would be provided by the
runtime. This is how the object may be defined:
\begin{ffcode}
+rt jvm org.eolang:eo-runtime:0.7.0
+rt ruby eolang:0.1.0
[text] > stdout /bool (*@\label{ln:stdout}@*)
\end{ffcode}
The \ff{/bool} suffix informs the compiler that this object must
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.
In the example above, there are two libraries specified: for JVM and
for Ruby.
The \ff{bool} part after the \ff{/} is the name of
object, which \ff{stdout} decorates. The name may be replaced by
a question mark, if uncertain about the object being decorated.
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}
An instance of an abstact object may need to have access to the
object where the abstract was defined, for example this is
how object \ff{tuple.map} is implemented in Objectionary:
\begin{ffcode}
[] > list (*@\label{ln:list-parent}@*)
[f] > mapi /list (*@\label{ln:list-map}@*)
[f] > map
^.mapi > @
[x i] (*@\label{ln:map-inner}@*)
&.f x > @
\end{ffcode}
The object \ff{mapi} at \lref{list-map} is an atom:
it iterates through list of items and makes
a copy of the provided two-arguments abstract object \ff{f} applying the next
item to it and the index in the tuple (that is why the name with the ``i'' suffix).
The object \ff{map} does exactly the same, but doesn't provide the
index of each element to the inner abstract object.
The anonymous inner abstract object at \lref{map-inner}
has to get access to the attribute \ff{f} of \ff{map}.
However, \ff{\^{}.f} won't work, because the parent of it is a copy of \ff{mapi}, and the
parent of \ff{mapi} is the object \ff{list}.
Thus, there is no way to get access
to \ff{map.f} using parent attributes.
The \emph{home} attribute \ff{\&} helps here.
Once an abstract object at \lref{map-inner} is created, its
home attribute is set to the abstract object \ff{list} at \lref{list-parent}.
Its parent attribute \ff{\^{}} is also set to the object \ff{list},
but is later changed by the atom \ff{mapi} when a copy of it is being made.
However, the home attribute remains the same.

69
paper/sections/xmir.tex
View File

@ -1,69 +0,0 @@
Consider this sample \eolang{} snippet:
\begin{ffcode}
[x y] > app
42 > n!
[t] > read
minus.
n.neg
t
\end{ffcode}
It will be compiled to the following XMIR:
\begin{ffcode}
<o line="1" name="app">
<o line="1" name="x"/>
<o line="1" name="y"/>
<o base="int" const="" data="int"
line="2" name="n">42</o> (*@\label{ln:xml-data}@*)
<o line="3" name="read">
<o line="3" name="t"/>
<o base=".minus" line="4"> (*@\label{ln:xml-minus}@*)
<o base="n" line="5"/> (*@\label{ln:method-start}@*)
<o base=".neg" line="5" method=""/> (*@\label{ln:method-end}@*)
<o base="t" line="6"/>
</o> (*@\label{ln:xml-minus-end}@*)
</o>
</o>
\end{ffcode}
Each object is translated to XML element \ff{<o>}, which has
a number of optional attributes and a mandatory one: \ff{line}.
The attribute \ff{line} always contains a number of the
line where this object was seen in the source code.
The attribute \ff{name} contains the name of the object, if
it was specified with the \ff{>} syntax construct.
The attribute \ff{base} contains the name of the object, which
is being copied. If the name starts with a dot, this means
that it refers to the first \ff{<o>} child.
The attribute \ff{method} may be temporarily present, suggesting
further steps of XMIR transformations to modify the code
at \lrefs{xml-minus}{xml-minus-end} to the following (the attribute \ff{method}
goes away):
\begin{ffcode}
<o base=".minus" line="4"> (*@\label{ln:new-minus}@*)
<o base=".neg" line="5"/> (*@\label{ln:xml-neg}@*)
<o base="n" line="5"/>
</o> (*@\label{ln:xml-neg-end}@*)
<o base="t" line="6"/>
</o> (*@\label{ln:new-minus-end}@*)
\end{ffcode}
The semantics of the element \ff{.minus} at~\lref{xml-minus}
and the element \ff{.neg} at~\lref{xml-neg} are similar: prefix
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 \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{const} denotes a constant.