Want to contribute? Fork us in GitHub!

Parser of EO as an External Java Library

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.

Global EO Cache

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.

Pseudo-random generation in EO

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.

Introduced 'error' Object and new semantic of 'try' Object

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.

Placing and Unplacing in JAR Artifacts

The entire process of packaging EO objects and atoms into JAR artifacts is explained in this blog post: Objectionary: Dictionary and Factory for EO Objects. It’s pretty straight forward. However, there is one tricky situation related to placing compiled Java binaries into the JAR. This process may go wrong and sometimes it does. In version 0.24.0 of our Maven plugin we introduced a pair of options for the unplace goal. Here is how they work.

Introduced 'switch' Object

Since 0.23.16 version it is possible to use switch object just like this:

memory "swordfish" > password

QQ.switch
  *
    password.eq "swordfish"
    "password is correct!"
  *
    password.eq ""
    "empty password is not allowed"
  *
    FALSE
    "password is wrong"

Here, switch object returns “password is correct!”, which is the first true case in this statement. The switch object consists of arrays with arrays of two elements: condition and return value.

If the above parameters are missing, switch will return an error object with msg as a string message.

How to Compile Against a Fixed Version of Objectionary

When you compile your EO code, the compiler discovers which objects are “foreign” and tries to find them in Objectionary. It finds them, downloads, and then compiles locally. The problem is that the objects in Objectionary are not static: they get new versions very often. That’s why, in order to stabilize your build you may want to use their fixed versions.

Introduced 'number' Object

Since 0.23.15 version it is possible to use number object just like this:

# this is 7
(QQ.math.number -7).abs 

It is a decorator of int and float objects with the following additional attributes: