There are “atoms” in EO language, which are objects implemented by the runtime platform, not by a composition of other EO objects. Most notable examples of atoms are int.plus, float.times, and bool.while. Here is a quick intruction to creating your own atoms.

XMIR is a dialect of XML, which we use to represent a parsed EO program. It is a pretty simple format, which has a few important tricks, which I share below in this blog post. You may also want to check our schema: XMIR.xsd (it is also rendered in HTML, which may be more readable for some of you).

As described in this blog post place step of EO build process copies compiled files from dependencies’ JARs into target/classes folder to have them in classpath during compilation later. You can check PlaceMojo class for exact logic of this step.
All copied files are registered within “placed catalog,” which is normally stored as target/eo/placed.csv file. Let’s consider structure of the catalog in more details.

As in all other programming languages, an object while is used to iterate over a set of statements while a condition is true. In EO this object not only does this, but is also dataized. And the result of such dataization was the number of iterations performed. Now this behavior has changed: the result of such dataization can now be any object (depending on the condition). It can be divided into two parts: when the condition is TRUE and when the condition is FALSE.

EO parser is written in ANTLR4, Java, and XSL. It is packaged as a multi-module Maven project, in objectionary/eo GitHub repository. In order to compile an EO program to Java you may either use our Maven plugin or our eoc command line toolkit. Moreover, you can also use our parser programmatically in order to generate XMIR from EO. Here is how you do it in your Java/Kotlin/Clojure/Groovy/etc. project.

EO compilation process consists of several steps covered in details in this blog post. Most of the steps have various files (.eo, .xmir, etc.) as their input/output, and sometimes it’s very handy to have them persisted somewhere for reuse between compilation runs. ~/.eo/ folder acts as such persistent storage. Let’s have a closer look at its structure and how it is bound to compilation process.

EO library provides an ability to generate pseudo-random sequences. It’s analogous to Random class in Java or random module in Python.
Let’s explore how this facility (exposed via org.eolang.math.random object) can be used in EO.

Since 0.25.0 version it is possible to use error object just like this:

[x] > check
  if. > @
    x.eq 0
    error "Can't divide by zero"
    42.div x

Here, the object error causes program termination at the first attempt to dataize it. It encapsulates any other object, which can play the role of an exception that is floating to the upper level.

The object try enables the catching of an error objects and extracting exceptions from them. For example, the following code prints “The 1th argument of ‘int.div’ is invalid: division by zero is infinity” and then “finally”:

QQ.try
  []
    42.div 0 > @
  [e]
    QQ.io.stdout > @
      e
  []
    QQ.io.stdout > @
      "finally"

The object error encapsulates the error message from int.div object and terminates the program.