In one of the previous releases, we introduced this EO syntax for the automated naming of abstract objects. The only place where such auto-named abstract objects are allowed is as arguments of an application. They CAN’T be used as top-level abstract objects because that wouldn’t make any sense — there would be no way to “touch” them from other objects.

[x] >>     # prohibited

malloc.of
  12
  [m] >>   # allowed

The idea is simple: generate a random unique name for an object if the user considers meaningful naming unnecessary. But why might they decide this? That’s the most interesting part.

To understand the real reason, we need to go back to the previous blog post, particularly the section about the ρ (Rho) attribute. Let’s recap some important points:

1. The ρ (Rho) attribute of the object voice refers to the object animal that uses voice.
2. In EO, the ρ (Rho) attribute is indicated by the ^ sign.
3. “The object animal uses the object voice” implies dynamic dispatch.
4. Dynamic dispatch in EO is a mechanism for retrieving an attribute from an object. Syntactically, it is implemented via dot notation: animal.voice.
5. The ρ (Rho) attribute is initially empty and is set right after dynamic dispatch occurs.

[name] > animal
  [] > voice

animal "kitty" > cat
cat.voice > meow

In the code snippet above, we copy the object animal and set its attribute name to "kitty" (which is a string object). Then, we take the voice attribute from the object cat. At the exact moment the object voice is retrieved, its ρ (Rho) attribute is set and starts referring to the object cat. Now, we can do meow.^.

Considering the above, we can assume that for the object meow (which is a copied voice object) to use the ρ (Rho) attribute, voice must be “taken” (or dispatched) from somewhere (specifically, from the object cat). If it has to be “taken,” that means the object cat must have an attribute named voice, because dynamic dispatch is only possible via an attribute name. This is the key point: an object must have an attribute with a name. Only the presence of a name allows the object to have the ρ (Rho) attribute.

Now, let’s return to the example with abstract objects.

[] > foo
  "Hello" > greetings
  malloc.of > @
    5
    [m]
      $.^.greetings > str
      m.write str > @

Here, we have an object foo with two attributes: greetings and @. The attribute @ is bound to the object malloc.of, which is copied with two arguments: the object 5 and a nameless abstract object (let’s call it “scope”). The “scope” has three attributes: m, str, and @. As you can see, str is bound to a chain of dynamic dispatches: $.^.greetings.

Here, $ means “this” (i.e., the abstract object itself, “scope”); .^ takes the ρ (Rho) attribute of the abstract object; and .greetings retrieves the greetings attribute.

Clearly, “scope” is trying to access the greetings attribute of foo via its ρ (Rho) attribute. For this to work, “scope” must have the ρ attribute referring to foo, meaning that “scope” must be dispatched (or “taken”) from foo. However, “scope” lacks a name. No name means no dynamic dispatch, and without dynamic dispatch, there is no ρ (Rho) attribute.

The solution is simple: give a name to “scope”.

[] > foo
  "Hello" > greetings
  malloc.of > @
    5
    [m] > scope
      $.^.greetings > str
      m.write str > @

This is a sugared version where the name scope is placed at a certain nesting level. To better understand it, let’s rewrite it in its canonical form, which is semantically the same (and which our compiler actually builds under the hood).

[] > foo
  "Hello" > greetings
  [m] > scope
    $.^.greetings > str
    m.write str > @
  malloc.of > @
    5
    $.scope

Now, you can see that foo has one more attribute, scope, and the second argument of malloc.of now appears slightly different: $.scope. Take a closer look at it. What do you see? Right! This is dynamic dispatch we have here! The $ means “this” (i.e., the current abstract object, foo), and .scope retrieves the scope attribute from foo. This means that right after the dispatch is done, the scope object has its ρ attribute set, referring to foo, and $.^.greetings starts working correctly.

This solves the main problem. However, the canonical form is somewhat verbose, while the sugared form relies on attribute naming when it’s unnecessary.

For cases where an abstract object’s name is unimportant but must be present to enable dynamic dispatch, we introduced the >> syntax.

[] > foo
  "Hello" > greetings
  malloc.of > @
    5
    [m] >>
      $.^.greetings > str
      m.write str > @

Under the hood, the compiler rewrites it into something like this:

[] > foo
  "Hello" > greetings
  [m] > random-unique-name
    $.^.greetings > str
    m.write str > @
  malloc.of > @
    5
    $.random-unique-name

It continues to work according to the same rules but looks cleaner for the user.

That’s all for today. Hopefully, you now have a better understanding of the ρ attribute and dynamic dispatch in EO.

Where I Was Born

The first special attribute we’re observing (and which was removed) is σ (Sigma). The σ attribute of the object X was the attribute that referred to the object Y inside which the scope object X was born (formed or created for the first time).

The σ attribute in EO:

• was indicated by the & sign.
• was initialized right after the object is formed.
• every object except the global parent object Φ had it.

For example, int.& -> eolang, float.div.& -> float. Consider the next code snippet:

[] > loop
  "Hello, world" > str

  while > @
    true
    [i]
      stdout > @
        &.str

Here we have an endless while loop. The second argument of the object while is an anonymous abstract object, let’s call it X. The X object is not used in the scope of the object loop; it’s just created here. The object X will be used inside the scope of the object while when dataization is started. But as you may see X has access to the scope of the object loop via & and may reach the attributes of loop like str.

And we decided that it was a bad idea to give the object such an opportunity to have access to the place where it was born. It kind of breaks the idea of object orientation because & is actually a static attribute like a static method in Java. We don’t tolerate static methods and attributes, here’s why.

Who Uses Me

The second special attribute we’re observing is ρ (Rho). The ρ attribute of the object X is the attribute that refers to the object Y that uses the object X. In EO, the attribute ρ is indicated by the ^ sign. Drawing the analogy with Java, the closest thing to ρ is the this keyword which refers to the current object:

class Animal {
  String type;
  Animal(String tpe) {
    this.type = tpe;
  }
  void voice() {
    System.out.print("I'm a %s", this.type)
  }
}

Animal cat = new Animal("Cat");
cat.voice();                    // I'm a Cat

Animal dog = new Animal("Dog");
dog.voice();                    // I'm a Dog

Here we create two instances of Animal - cat and dog. The this keyword inside their voice functions refers to different objects - cat and dog accordingly.

The same functionality can be achieved in EO:

[type] > animal
  [] > voice
    stdout > @
      sprintf
        "I'm a %s"
        ^.type

animal "Cat" > cat
cat.voice > meow   # I'm a Cat

animal "Dog" > dog
dog.voice > woof   # I'm a Dog

The main difference between this in Java and ρ in EO is the moment when these “links” actually become referred to the objects. In Java - right after the object is created, in EO - on attribute dispatch. Let’s look a bit closer. The dynamic dispatch in EO is a mechanism of retrieving an attribute from the object. Syntactically it’s implemented via “dot-notation”.

So this is dispatch:

cat.voice

We’re trying to retrieve an attribute voice from the concrete object cat. At the moment we’ve found the attribute voice inside the object cat and are ready to return it - the voice attribute is copied and its ρ attribute is initialized with a link to the object cat. Until we touch the cat.voice object, its ρ attribute refers to Ø (nothing).

A few more examples:

cat.voice > voice1  # voice1.^ -> cat
cat.voice > voice2  # voice2.^ -> cat
dog.voice > voice3  # voice3.^ -> dog

cat.voice > voice4  # voice4.& -> animal - deprecated
dog.voice > voice5  # voice5.& -> animal - deprecated

What I Decorate

The third special attribute we’re observing is φ (Phi). We’ve already described the attribute in one of the previous blog posts, but let’s dive a bit deeper. In EO, the attribute is indicated by @ sign. The attribute is not mandatory and may be absent. The φ attribute of the object X is the attribute that refers to the object Y which object X decorates. The main purpose of decoration is the reuse of attributes. For example:

[type] > animal
  [] > voice
    stdout > @
      sprintf
        "I'm a %s"
        ^.type

[] > cat
  animal "Cat" > @

Here we have an object cat which decorates an object animal with type attribute set to "Cat". That means that all the attributes which are allowed to be taken from the object animal, like voice, are allowed to be taken from the object cat:

cat.voice > meow # I'm a Cat

The decoration may have several layers and all the attributes on the deepest level are available on the top level:

[type] > animal
  [] > voice
    stdout > @
      sprintf
        "I'm a %s"
        ^.type

[color] > cat
  animal > @
    sprintf
      "%s cat"
      color

[] > black-cat
  cat "black" > @

Here the object black-cat decorates the object cat and the object cat decorates the object animal. This onion of decorators allows taking the attribute voice from the object black-cat:

black-cat.voice > meow # I'm a black cat

What Data I Have

The fourth special thing we’re observing is Δ (Delta) asset. A few words about this asset:

• It’s not an attribute but an asset because it refers not to the object but to the data which is a sequence of bytes.
• There’s no way to explicitly touch this asset in EO.
• Only org.eolang.bytes object has this asset.
• The only way to touch the data in the asset is dataization.

What I Can Reach from Outside

The last special thing we’re observing is λ (Lambda) asset. Let’s look at it a bit closely:

• It’s not an attribute but an asset because it refers not to the object but to some external function which returns an object.
• Objects in EO that have the λ asset are called “atoms”.
• There’s no way to explicitly touch this asset in EO.
• Atoms can’t have a φ attribute.
• The λ asset, as well as the φ attribute, also allows reusing the attributes:

[] > mars-temperature /float # measures the temperature on Mars and returns float

mars-temperature.div 10 > divided

Here, as you may see, mars-temperature is the atom that does not have an attribute div and returns float. However, we can still retrieve the attribute div from it. It will go to the λ asset, execute it, do some calculations, return us some float, and the div attribute will be taken from this float.

That’s all for today. We’ll be right back in a week with a new fresh blog post. Stay in touch.

The @ attribute is a special attribute that indicates the current object decorates another object. For example, in the snippet below, objects cat and dog decorate an object animal:

[voice] > animal

[] > cat
  animal "Meow" > @

[] > dog
  animal "Woof" > @

The attribute @ is also often used in nameless abstract objects. A common example is the second argument of the object try:

try
  1.div 0
  [e]
    QQ.io.stdout > @
      e
  true

We noticed quite some time ago that there were so many small objects with only the @ attribute bound. So, to simplify the code and reduce the number of indentations, we introduced new syntax for such objects:

QQ.io.stdout e > [e]

# Which is the same as

[e]
  QQ.io.stdout e > @

# OR

[e]
  QQ.io.stdout > @
    e

It’s worth noting that only objects in horizontal notation can be used with such syntax:

QQ.io.stdout e > [e]       # horizontal application, the same as:
                           # [e]
                           #   QQ.io.stdout e > @
                           #
if. true first second > [] # reversed horizontal application, the same as:
                           # []
                           #   if. > @
                           #     true
                           #     first
                           #     second
                           # OR
                           # []
                           #   if. true first second > @
                           #
QQ.io.stdout > []          # horizontal method/dispatch, the same as:
                           # []
                           #   QQ.io.stdout > @
                           #
x > []                     # object reference, the same as:
                           # []
                           #   x > @
                           # OR
                           # [] (x > @)
                           #
[x] (5.plus x > sum) > [i] # horizontal anonymous abstract object
                           # the same as:
                           # [i]
                           #   [x] > @
                           #     5.plus x > sum

All objects in vertical notation can NOT be used with such syntax and their usage leads to a parsing exception:

QQ.io.stdout > [e]         # vertical application - wrong
  e                        #
                           #
QQ                         # vertical method/dispatch - wrong
.io                        #
.stdout > [e]              #
                           #
if. > @                    # reversed vertical method with application - wrong
  true                     #
  first                    #
  second                   #
                           #
[x] > [i]                  # vertical anonymous abstract object - wrong
  5.plus x > sum           #

Returning to the example with object try, it can now be written in a shorter and more convenient way:

try
  1.div 0
  QQ.io.stdout e > [e]
  true

That’s all for today. We’ll be right back in a week with a new fresh blog post. Stay in touch.

The idea is simple: instead of one object bool, we introduced two new objects, true and false, which decorate specific bytes, 01- and 00-, respectively.

[] > true
  01- > @

[] > false
  00- > @

Such an implementation has the following benefits:

• There’s no way to create a boolean object with an unexpected amount of bytes.
• We got rid of the atom if and defined it right inside true and false:

[] > true
  01- > @

  [left right] > if
    left > @

[] > false
  00- > @

  [left right] > if
    right > @

The decision on which if branch we should jump to is transferred to the moment of creation of the objects true or false.

• We got rid of two literals TRUE and FALSE in EO grammar.
• The implementation of other bool objects like and, or, not became simpler.

So, the result true and false objects now look like:

[] > true
  01- > @
  false > not

  [left right] > if
    left > @

  [x] > and
    01-.eq x > @

  [x] > or
    ^ > @

[] > false
  00- > @
  true > @

  [left right] > if
    right > @

  [x] > and
    ^ > @

  [x] > or
    01-.eq x > @

That’s it for today. There are more interesting features we introduced in the last release. We’re planning to write blog posts about all of them because they’re worth it. So keep following us!

Rho attribute

The first significant change is related to the special ρ (rho) attribute. A few words about it:

• In general, the ρ attribute refers to the “parent” (or context) of the object. In Java, an analog of ρ would be the this keyword.
• Every object has a ρ attribute.
• At the beginning, when an object is formed (just created for the first time), its ρ is void (referring to nothing).
• ρ is immutable and may be set only once (the rules of setting will be described in a future blog post).

Vertex attribute

The second significant change is related to the ν (vertex) attribute. We got rid of it and made our language simpler.

The purpose of the ν attribute was to uniquely identify an object in the universe. Before the release 0.36.0, every object had such a unique numeric identifier, and EO guaranteed that. However, we decided that giving such badges to objects is not really object-oriented. We don’t want and don’t need to interact with objects relying on whether they have some unique ID. All we want from the object is its behavior, the functionality it provides. So, it just does not matter if an object has some identifier or not; the way it behaves with us is what really matters.

That’s why objects in EO don’t have the ν attribute anymore.

Caching

We’ve changed the logic of object caching in EO.

some-object > cached!

Until now, this ! meant that if we take attributes from the object more than once, they will be calculated only the first time and cached. Sounds good, but it didn’t work as we wanted.

Now, ! means that when a cached object is touched for the first time (for example, an attribute is taken), it’s dataized, converted to bytes, and starts to behave as the bytes. All the next manipulations with the cached object are transferred to the given bytes.

Objects

We’ve done a lot of work to remove redundant objects, redesign some old ones, and introduce new ones.

• The object while was removed from bool and became a separated object written in pure EO. Its logic is still declarative as it was before.
• The object if also was removed from bool and became a separated object.
• The object goto was implemented in pure EO.
• The object dataized was introduced. This object dataizes its argument, makes a new instance of the bytes object, and behaves as it.
• The objects ram and heap were removed.
• The object malloc was introduced. It’s a classic memory management object that can allocate a block in memory, write to it, read from it, and free it.
• The object memory was redesigned and implemented in pure EO. It uses the objects dataized and malloc inside.
• The object cage was redesigned. But it’s still a “bad” object, which does not belong to EO.

Grammar

We’ve made EO more strict by making changes in its grammar rules:

• Empty lines inside an abstract object body are prohibited. Only one line in front of an abstract object is allowed.

# Wrong.
[] > object

  5 > five

  10 > ten

  [] > inner

# Right.
[] > object
  5 > five
  10 > ten

  [] > inner

• A comment in front of a named abstract object is mandatory. A comment in front of an anonymous (unnamed) abstract object is prohibited. The mandatory comment must start with a capital letter, end with a dot, have a length >= 64 characters, and include only printable characters (0x20-0x7f). Comments in front of other top-level objects are optional.

# This is a good commentary in front of a named abstract object with a length >= 64 characters.
[] > object
  # This comment is optional but has the same requirements as in front of an abstract object.
  while > @
    TRUE
    # This commentary is prohibited and will lead to a parsing exception being thrown.
    [i] (i > @)

• The ν (vertex) attribute is removed from the grammar.

# This code won't be parsed.
TRUE.< > vtx

• Explicit object copying via ' is removed. Until now, the main purpose of explicit object copying was to create a new object with a new ν (vertex) attribute. But since we got rid of it, there’s no more sense in having such an operation in EO.

# This code won't be parsed.
TRUE' > copy

• Object caching via ! is no longer a language feature but just syntax sugar for the dataized object.

some-object > cached!
# The same as
(dataized some-object).as-bytes > cached

That’s it. This is what we were working on for the last 4 months. We’ll try not to make such huge breaks between blog posts in the future. So keep following us!

Recursive tuple

As it was mentioned in the previous blog post, EO is based on φ-calculus, which is a formal model that we are attempting to use as a base for object-oriented programming languages. There are only two fundamental entities in the calculus - objects and data. An object is a collection of uniquely named attributes and data is just a sequence of bytes.

There’s also a special attribute Δ(delta) which is attached to the data. In our vision of EO only one object should have such an attribute - bytes. But for a long time at least 6 objects had it: bytes, int, float, string, bool and (surprise) tuple. The Δ attribute of tuple stored an array of Java Phi objects, which was totally wrong.

But the decision was made - only bytes should have a Δ attribute, so we needed to remove it from the other 5 objects including tuple. And it was a good chance to rewrite tuple in pure EO which allowed us to decrease the number of atoms.

So, welcome new implementation of tuple written in pure EO:

# Tuple.
[head tail] > tuple
  # Empty tuple
  [] > empty
    [i] > at
      error "Can't get an object from the empty tuple" > @
    [x] > with
      tuple > @
        tuple.empty
        x
    0 > length

  # Obtain the length of the tuple.
  [] > length
    ^.head.length.plus 1 > @

  # Take one element from the tuple, at the given position.
  [i] > at
    ^.length > len!
    if. > index!
      i.lt 0
      len.plus i
      i
    if. > @
      or.
        index.lt 0
        index.gte len
      error "Given index is out of tuple bounds"
      if.
        index.lt (len.plus -1)
        ^.head.at index
        ^.tail

  # Create a new tuple with this element added to the end of it.
  [x] > with
    tuple > @
      ^
      x

As you may see, tuple has two free attributes now: head and tail; where head is always supposed to be a tuple as well and tail is the object we want to store.

For example, if we want to create a tuple of one object it would look like this:

tuple > my-tuple
  tuple.empty
  1

The tuple.empty is a special tuple that stores nothing and is used as a top-level tuple in the whole recursion.

If we want to create a tuple of three objects it would look like this:

tuple > my-tuple
  tuple
    tuple
      tuple.empty
      1
    2
  3

I hope you get the idea. We also left the *(star) syntax sugar which allows you to write a tuple in one line:

* 1 2 3 > my-tuple

This example is equivalent to the previous one and will be transformed by the compiler to it.

Varargs

Before the release 0.34.0 there were varargs in EO which allowed you to have an object with an uncertain number of free attributes. For example, the int.plus object looked something like this:

[] > int
  [x...] > plus
    # code here

5.plus 5 10 > twenty
20.plus 1 2 3 4 > thirty

It was quite a convenient mechanism, but it didn’t match φ-calculus where every attribute has to be attached to the concrete object. With varargs, the application 5.plus 5 10 looks something like this:

Φ.org.eolang.int(Δ ⤍ 5).plus(
  α0 ↦ Φ.org.eolang.int(Δ ⤍ 5),
  α1 ↦ Φ.org.eolang.int(Δ ⤍ 10)
)

But there aren’t two free attributes in the formation of int.plus, only one — x:

Φ ↦ ⟦org ↦ ⟦eolang ↦ ⟦int ↦ ⟦plus ↦ ⟦x ↦ ∅, ...⟧, ...⟧, ...⟧, ...⟧, ...⟧

So as not to complicate things, we decided to get rid of varargs in EO altogether. And now it’s a perfect match between EO and φ-calculus. Of course, readability suffered a little because of it, but it’s worth it.

Next time we’ll put an end to data primitives, be in touch.

As you may know, φ-calculus is a formal model that we are attempting to use as a base for object-oriented programming languages, including EO.

From now on, it is possible to convert a program written in EO to a φ-calculus expression. Here’s how you can accomplish this in your personal project.

First, you need to add the eo-maven-plugin dependency:

<dependency>
  <groupId>org.eolang</groupId>
  <artifactId>eo-maven-plugin</artifactId>
  <version>0.34.0</version> <!-- use 0.34.0 or younger -->
</dependency>

Conversion occurs in four stages: registration, parsing, optimization, and actual conversion. Therefore, include the corresponding goals in your build pipeline:

<build>
  <plugins>
    <plugin>
      <groupId>org.eolang</groupId>
      <artifactId>eo-maven-plugin</artifactId>
      <version><!-- use the last version --></version>
      <executions>
        <execution>
          <id>convert</id>
          <goals>
            <goal>register</goal>
            <goal>parse</goal>
            <goal>optimize</goal>
            <goal>xmir-to-phi</goal>
          </goals>
        </execution>
        <configuration>
          <sourcesDir><!-- Where .eo source is placed, src/main/eo by default --></sourcesDir>
          <phiOutputDir><!-- Where .phi files are placed target/eo/phi by default --></phiOutputDir>
        </configuration>
      </executions>
    </plugin>
  </plugins>
</build>

Now, you are ready to convert an EO program to a φ-calculus expression. Place the .eo file in the source directory and run your Maven project. When it’s done, files with the .phi extension are placed in the phiOutputDir directory.

You may also convert a φ-calculus expression back to EO. For this, your build pipeline should look like:

<build>
  <plugins>
    <plugin>
      <groupId>org.eolang</groupId>
      <artifactId>eo-maven-plugin</artifactId>
      <version><!-- use the last version --></version>
      <executions>
        <execution>
          <id>convert</id>
          <goals>
            <goal>phi-to-xmir</goal>
            <goal>optimize</goal>
            <goal>print</goal>
          </goals>
        </execution>
        <configuration>
          <unphiInputDir><!-- Where .phi source is placed, target/eo/phi by default --></unphiInputDir>
          <printSourcesDir>${project.basedir}/target/eo/2-optimize</printSourcesDir> <!-- /src/main/xmir by default -->
          <printOutputDir><!-- Where result .eo files are placed, target/generated-sources/eo by default --></printOutputDir>
        </configuration>
      </executions>
    </plugin>
  </plugins>
</build>

When it’s done, the resulting .eo files are placed in the output printOutputDir directory.

Here’s an example of how the EO Fibonacci program looks in φ-calculus (you can find more examples here):

+package eo.example

[n] > fibonacci
  if. > @
    lt.
      n
      2
    n
    plus.
      fibonacci
        n.minus 1
      fibonacci
        n.minus 2

Its XMIR representation (default location is target/eo/2-optimize):

<?xml version="1.0" encoding="UTF-8"?>
<program dob="2023-03-19T00:00:00"
         ms="12"
         name="foo.x.main"
         revision="1234567"
         source="/var/folders/xj/f4s949893tq37zzw0pdmd68h0000gn/T/junit2727451398454004374/foo/x/main.eo"
         time="2023-12-13T10:04:53.022835Z"
         version="0.0-SNAPSHOT">
   <!--This is XMIR - a dialect of XML, which is used to present a parsed EO program. For more information please visit https://news.eolang.org/2022-11-25-xmir-guide.html-->
   <listing>+package eo.example

[n] &gt; fibonacci
  if. &gt; @
    lt.
      n
      2
    n
    plus.
      fibonacci
        n.minus 1
      fibonacci
        n.minus 2
</listing>
   <errors>
      <error check="missing-home"
             line=""
             severity="warning"
             sheet="mandatory-home-meta"
             step="0">Missing home</error>
      <error check="missing-version-meta"
             line=""
             severity="warning"
             sheet="mandatory-version-meta"
             step="0">Missing version meta</error>
   </errors>
   <sheets>
      <sheet>not-empty-atoms</sheet>
      <sheet>duplicate-names</sheet>
      <sheet>many-free-attributes</sheet>
      <sheet>broken-aliases</sheet>
      <sheet>duplicate-aliases</sheet>
      <sheet>global-nonames</sheet>
      <sheet>same-line-names</sheet>
      <sheet>self-naming</sheet>
      <sheet>cti-adds-errors</sheet>
      <sheet>add-refs</sheet>
      <sheet>wrap-method-calls</sheet>
      <sheet>expand-qqs</sheet>
      <sheet>add-probes</sheet>
      <sheet>vars-float-up</sheet>
      <sheet>add-refs</sheet>
      <sheet>sparse-decoration</sheet>
      <sheet>unsorted-metas</sheet>
      <sheet>incorrect-architect</sheet>
      <sheet>incorrect-home</sheet>
      <sheet>incorrect-version</sheet>
      <sheet>expand-aliases</sheet>
      <sheet>resolve-aliases</sheet>
      <sheet>add-refs</sheet>
      <sheet>add-default-package</sheet>
      <sheet>broken-refs</sheet>
      <sheet>unknown-names</sheet>
      <sheet>noname-attributes</sheet>
      <sheet>duplicate-names</sheet>
      <sheet>duplicate-metas</sheet>
      <sheet>mandatory-package-meta</sheet>
      <sheet>mandatory-home-meta</sheet>
      <sheet>mandatory-version-meta</sheet>
      <sheet>correct-package-meta</sheet>
      <sheet>prohibited-package</sheet>
      <sheet>external-weak-typed-atoms</sheet>
      <sheet>unused-aliases</sheet>
      <sheet>unit-test-without-phi</sheet>
      <sheet>explicit-data</sheet>
      <sheet>set-locators</sheet>
   </sheets>
   <license/>
   <metas>
      <meta line="1">
         <head>package</head>
         <tail>eo.example</tail>
         <part>eo.example</part>
      </meta>
      <meta line="4">
         <head>probe</head>
         <tail>n.lt.if</tail>
         <part>n.lt.if</part>
      </meta>
   </metas>
   <objects>
      <o abstract=""
         line="3"
         loc="Φ.eo.example.fibonacci"
         name="fibonacci"
         pos="0">
         <o line="3" loc="Φ.eo.example.fibonacci.n" name="n" pos="1"/>
         <o base=".if"
            line="4"
            loc="Φ.eo.example.fibonacci.φ"
            name="@"
            pos="2">
            <o base=".lt" line="5" loc="Φ.eo.example.fibonacci.φ.ρ" pos="4">
               <o base="n"
                  line="6"
                  loc="Φ.eo.example.fibonacci.φ.ρ.ρ"
                  pos="6"
                  ref="3"/>
               <o base="org.eolang.int"
                  line="7"
                  loc="Φ.eo.example.fibonacci.φ.ρ.α0"
                  pos="6">
                  <o base="org.eolang.bytes"
                     data="bytes"
                     loc="Φ.eo.example.fibonacci.φ.ρ.α0.α0">00 00 00 00 00 00 00 02</o>
               </o>
            </o>
            <o base="n"
               line="8"
               loc="Φ.eo.example.fibonacci.φ.α0"
               pos="4"
               ref="3"/>
            <o base=".plus" line="9" loc="Φ.eo.example.fibonacci.φ.α1" pos="4">
               <o base="fibonacci"
                  line="10"
                  loc="Φ.eo.example.fibonacci.φ.α1.ρ"
                  pos="6"
                  ref="3">
                  <o base=".minus"
                     line="11"
                     loc="Φ.eo.example.fibonacci.φ.α1.ρ.α0"
                     pos="9">
                     <o base="n"
                        line="11"
                        loc="Φ.eo.example.fibonacci.φ.α1.ρ.α0.ρ"
                        pos="8"
                        ref="3"/>
                     <o base="org.eolang.int"
                        line="11"
                        loc="Φ.eo.example.fibonacci.φ.α1.ρ.α0.α0"
                        pos="16">
                        <o base="org.eolang.bytes"
                           data="bytes"
                           loc="Φ.eo.example.fibonacci.φ.α1.ρ.α0.α0.α0">00 00 00 00 00 00 00 01</o>
                     </o>
                  </o>
               </o>
               <o base="fibonacci"
                  line="12"
                  loc="Φ.eo.example.fibonacci.φ.α1.α0"
                  pos="6"
                  ref="3">
                  <o base=".minus"
                     line="13"
                     loc="Φ.eo.example.fibonacci.φ.α1.α0.α0"
                     pos="9">
                     <o base="n"
                        line="13"
                        loc="Φ.eo.example.fibonacci.φ.α1.α0.α0.ρ"
                        pos="8"
                        ref="3"/>
                     <o base="org.eolang.int"
                        line="13"
                        loc="Φ.eo.example.fibonacci.φ.α1.α0.α0.α0"
                        pos="16">
                        <o base="org.eolang.bytes"
                           data="bytes"
                           loc="Φ.eo.example.fibonacci.φ.α1.α0.α0.α0.α0">00 00 00 00 00 00 00 02</o>
                     </o>
                  </o>
               </o>
            </o>
         </o>
      </o>
   </objects>
</program>

And its φ-calculus representation:

{
    eo ↦ ⟦
        example ↦ ⟦
            fibonacci ↦ ⟦
                n ↦ ∅,
                φ ↦ ξ.n.lt(
                    α0 ↦ Φ.org.eolang.int(
                        α0 ↦ Φ.org.eolang.bytes(Δ ⤍ 00-00-00-00-00-00-00-02)
                    )
                ).if(
                    α0 ↦ ξ.n,
                    α1 ↦ ξ.ρ.fibonacci(
                        α0 ↦ ξ.n.minus(
                            α0 ↦ Φ.org.eolang.int(
                                α0 ↦ Φ.org.eolang.bytes(Δ ⤍ 00-00-00-00-00-00-00-01)
                            )
                        )
                    ).plus(
                        α0 ↦ ξ.ρ.fibonacci(
                            α0 ↦ ξ.n.minus(
                                α0 ↦ Φ.org.eolang.int(
                                    α0 ↦ Φ.org.eolang.bytes(Δ ⤍ 00-00-00-00-00-00-00-02)
                                )
                            )
                        )
                    )
                )
            ⟧,
            λ ⤍ Package
        ⟧,
        λ ⤍ Package
    ⟧
}

That’s it for now, be in touch.

Understanding the $ Object

Upon encountering the $ symbol in EO code, it is important to recognize its true significance. The $ object essentially serves as a reference to the abstract object within which it is utilized. By leveraging this syntactic sugar, developers can harness the power of the current object without explicitly referring to it by name. This concise and intuitive approach enhances code clarity and conciseness, leading to more efficient and maintainable codebases.

An Example

Let’s examine a code snippet to better understand how the $ object functions within the EO programming language:

[] > foo
  assert-that > @
    2.plus 2
    $.equal-to 4

In this example, we define an abstract object named foo. Within the assert-that scope, we pass the 2.plus 2 object as the parameter to it, and the second object’s matcher, then verify whether it is equal to 4, using the $ object as a reference. Upon initial inspection, the code may seem a bit puzzling. However, we can break it down to reveal its true meaning:

1. Firstly, $ refers to the nearest abstract object, foo:

   [] > foo
     assert-that > @
    2.plus 2
    foo.equal-to 4
   

   But the foo object does not have an equal-to object. So, the EO compiler needs to find an object that has the equal-to object.

2. Secondly, the EO compiler tries to get foo.@ and take equal-to from there:

   [] > foo
     assert-that > @
    2.plus 2
    foo.@.equal-to 4
   

3. Finally, the compiler finds the equal-to object in the assert-that object and takes it from there:

   [] > foo
     assert-that > @
    2.plus 2
    assert-that.equal-to 4
   

   By using $ as a reference, we can directly access the assert-that object while within the foo scope. Here is the example of the assert-that object for better understanding:

[actual matcher] > assert-that
...
  [expected] > equal-to
    actual.eq expected > @

Practical Applications of the $ Object

Undoubtedly, the $ object’s syntactic sugar provides programmers with a clean and expressive way to work with objects. The following scenarios highlight its practical applications:

1. Chaining Methods: By utilizing the $ object, we can succinctly chain methods together, simplifying complex operations. This leads to more readable and concise code, enhancing collaboration among team members and reducing the chances of introducing bugs.
2. Context Independence: The $ object allows developers to maintain the context of their code while reducing the need for lengthy and repetitive object references. It facilitates writing clean and modular code that is easier to understand and maintain.

Conclusion

In conclusion, the $ object serves as vital syntactic sugar in the EO programming language, offering developers an elegant way to refer to the current abstract object within their code. By leveraging this feature, programmers can enhance the readability and conciseness of their code, ultimately improving collaboration and productivity. Understanding the true meaning behind the $ object allows developers to unlock its full potential and leverage it in various scenarios, from method chaining to context independence.

So, embrace the $ object and embrace the power of EO programming!

Until recently, the comparison of 0.0 and -0.0 in EO didn’t work like in other languages, but we changed that. This short blog post provides a simplified explanation of number encodings, how such comparison takes place in popular programming languages, and how we changed this comparison in EO to meet the standard.

Why do we have two zeros?

Without delving into the intricacies of number encoding and standards, let’s briefly understand why this happens.

The familiar signed int works based on the two’s complement principle, in which zero has a unique representation (all bits are 0).

On the other hand, float operates differently, using the IEEE 754 standard for encoding and arithmetic operations. In this standard, numbers have a sign bit. If the sign bit is 1, the number is negative; if it’s 0, the number is positive. As a result, we have two different binary representations of float zero: 0.0 has all zeros in its binary representation, while -0.0 has all zeros except for the sign bit.

Comparison of 0.0 and -0.0 in EO before the changes

EO comparison used to work as follows:

0.0.eq -0.0 # FALSE
0.0.gt -0.0 # FALSE
0.0.lt -0.0 # FALSE
0.0.gte -0.0 # FALSE
0.0.lte -0.0 # FALSE

This happened because the eq attribute compared data within objects bitwise. In simpler terms, regardless of the data being compared, it was first interpreted as a set of bits and then compared.

Thus, due to the fact that numbers 0.0 and -0.0, as previously determined, have different bitwise representations, when compared in EO using eq, they turned out to be not equal.

Comparison of 0.0 and -0.0 in other languages

In most mainstream programming languages 0.0 is considered equal to -0.0 in basic equality comparisons. For example, in Java, C++, JavaScript, and Python, the comparison of these values works as follows:

0.0 == -0.0 // true
0.0 < -0.0 // false
0.0 > -0.0 // false
0.0 <= -0.0 // true
0.0 >= -0.0 // true

Why do these languages consider 0.0 and -0.0 as equal, even though they have different bitwise representations? The same IEEE 754 standard states that “negative zero and positive zero should compare as equal with the usual (numerical) comparison operators” (referencing the standard in the blog post isn’t possible as it’s a paid document, but you can find this information here).

Thus, this behavior for float numbers is built into most CPUs and works at the assembler level. Comparison operators, such as ==, in the languages discussed above, correspond to how it is implemented in the hardware. This is indeed the case in most languages.

Comparison of 0.0 and -0.0 in EO now

In order for the floating-point comparison in EO to comply with the standard, we have changed the behavior of the eq attribute for float. After these changes, the comparison of 0.0 and -0.0 behaves as follows:

0.0.eq -0.0 # TRUE
0.0.gt -0.0 # FALSE
0.0.lt -0.0 # FALSE
0.0.gte -0.0 # TRUE
0.0.lte -0.0 # TRUE

Now it works like in all popular programming languages. It’s worth noting that we didn’t add extra atoms (you can read more about atoms in this blog post). The eq attribute still compares floats bitwise; we simply added a special condition for zeros.

Conclusion

We changed the eq attribute of float to meet the IEEE 754 standard. Significant reasons are needed to deviate from the standard, so we decided that it would be more correct to do as in other programming languages.

This blog post will attempt to explain what application is under the hood, how it works in our compiler, and why this code (arr.at 0) "Hello" does not work in the way you expect.

Application

Application is the process of copying an abstract object while specifying some of its free attributes.

Consider the example. Here, dog is an abstract object with one free attribute: name.

[name] > dog
  stdout > bark
    sprintf
      "I'm %s! Woof!"
      name

Abstract objects are like templates or factories for concrete objects. So, getting a specific instance of a dog occurs in two stages: copying and setting a free attribute. The copying process takes place behind the scenes. Thus, we obtain a new specified object, dog, with its name as “Bary”.

dog "Bary" > bary

At the Java level (into which EO is being translated), application looks something like this:

Phi dog = Phi.Ф.attr("org.eolang.dog").get(); // finding an abstract object "dog"
Phi copy = dog.copy();                        // copying/cloning an abstract object
copy.attr("name").put("Bary");                // setting the free attribute

As you can see, no object execution occurs. It’s vital to note and remember that everything that happens during the application involves getting a new object by copying and setting its internal state. Nothing more.

Application to application

However, despite knowing what application is, we encountered an interesting problem for which we couldn’t find a solution for a long time.

Consider the following code:

1. [name] > dog
2.   "I'm %s! Woof!" > bark
3. * dog > arr
4. (arr.at 0) "Bary" > bary

• As before, dog is an abstract object with one free attribute, name.
• In the third line, an abstract object dog is stored in an array.
• In the fourth line, we attempt to retrieve an abstract object dog from the array by applying object 0 to arr.at (in simpler words, we’re trying to access the first element of the array) and then set the object "Bary" as the free attribute name of the dog.

We can try to clarify the code like this:

1. [name] > dog
2.   "I'm %s! Woof!" > bark
3. * dog > arr
4. arr.at 0 > first
5. first "Bary" > bary

It appears that everything is fine, and the code should work, but it doesn’t, and moreover, it must not.

What’s wrong

It all comes down to the application discussed earlier. No object execution occurs during the application. So if you take a closer look at the fourth line:

4. arr.at 0 > first

there is no information about what’s inside the array. It simply sets the object 0 as the free attribute of the object arr.at, and that’s it.

And what happens next in the fifth line:

5. first "Bary" > bary

We’re taking an object first (which is just a reference to the object arr.at with an already specified free attribute) and then trying to specify its free attribute again.

And obviously (perhaps not so obvious), this leads to an error because we’re trying to set the same free attribute twice.

So, what’s the solution?

Firstly, code where application is placed at the “head” of another application is now prohibited at the grammar level:

(arr.at 0) "Bary"

Secondly, we found out that such cases can be easily resolved with code like this:

(arr.at 0).@ "Bary" > bary

Here, we first specify the free attribute of the object arr.at, and then we access its @ attribute and apply the object "Bary" to it.

The information about the abstract object dog stored inside the array is revealed when we access the @ attribute of the object arr.at.

In this particular case, arr.at.@ is a so-called lambda object that performs calculations and returns the object from the array by providing an index. It’s worth noting that if the free attribute of arr.at is not specified, the following code:

arr.at.@

will fail with an error.

I hope you’ve learned a little more about EO today. Stay tuned for updates and be in touch!