mirror of
https://github.com/objectionary/eo.git
synced 2024-09-11 12:45:42 +03:00
paper removed
This commit is contained in:
parent
6f50ce2673
commit
073a1f8d1f
21
.github/workflows/latexmk.yml
vendored
21
.github/workflows/latexmk.yml
vendored
@ -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
19
paper/.gitignore
vendored
@ -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/
|
@ -1,2 +0,0 @@
|
||||
$pdflatex = 'pdflatex %O -interaction=errorstopmode -shell-escape -halt-on-error %S';
|
||||
$success_cmd = 'texqc && texsc';
|
@ -1,5 +0,0 @@
|
||||
{
|
||||
"checks": {
|
||||
"typography.symbols.curly_quotes": false
|
||||
}
|
||||
}
|
16
paper/.texsc
16
paper/.texsc
@ -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
|
@ -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
|
@ -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
|
||||
|
@ -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).
|
@ -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
|
@ -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
802
paper/main.bib
@ -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},
|
||||
}
|
||||
|
@ -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
|
@ -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{}.
|
||||
|
@ -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}
|
||||
|
@ -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.
|
@ -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.
|
||||
|
||||
|
||||
|
||||
|
@ -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.
|
||||
|
||||
|
||||
|
@ -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.
|
||||
|
@ -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}
|
||||
|
@ -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.
|
||||
|
@ -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.
|
||||
|
@ -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*}
|
||||
|
@ -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.
|
@ -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.
|
Loading…
Reference in New Issue
Block a user