Translation into Elixir

by Oleg Sovetnik

When selecting the language and framework for implementing the umwelt, the primary focus was on choosing the paradigm that would form the foundation of the system. I decided on Elixir, which represents the functional paradigm and allows for effective work with pure functions, data streams, the actor model, and data immutability.

Why Elixir?

1. Functional paradigm and actor model. Umwelt operates with concepts and facts, which represent the interpretation of data through mediators—essentially pure functions. For more complex processes that exist over time and have a lifecycle, Elixir uses built-in GenServer or Agent, which is ideal for modeling dynamic systems and agent interactions.
2. Macro system. Elixir provides a powerful macro system that allows for the creation of high-level abstractions. This simplifies working with syntactic structures necessary for translating concepts and facts into code.
3. Abstract Syntax Tree (AST). Elixir’s standard library includes an AST system, which simplifies working with code at the parsing and generation level, crucial for automatically generating tests and code based on the umwelt.
4. Testing integration. Elixir has built-in testing tools (ExUnit), allowing for seamless integration of the testing process into the umwelt. This makes it easier to automatically create and run tests based on generated specifications.

Why Phoenix?

1. Modular structure. Phoenix supports project logic division into contexts, making it easier to organize entities and repositories. This creates a convenient infrastructure for integrating the umwelt as a separate project component.
2. Easy integration with Elixir. Phoenix works on top of Elixir, allowing the umwelt to be easily used in web applications while retaining the benefits of the functional paradigm and the powerful actor system.

To connect umwelt concepts and facts to Elixir code, we need to establish clear translation rules. This process involves mapping elements of the conceptual tree to modules, structures, functions, and tests. We’ve identified several types of elements that can be transformed into code:

Concept

In code, a concept becomes a module. A module exists in the context of the root or another module.

Attribute

A concept’s constant attributes become the module’s attributes.

Structure

A structure is created if the concept has at least one field. The type is defined based on the structure’s fields.

Example

If the concept has fields and is thus a structure, we can create examples that belong to the set of this type.

Field

If the concept has operands (properties), we can describe them as structure fields, specifying their type and default value.

Signature

This is the function header or bodyless function needed to abstractly describe the mediator. We define the arguments, their types, and the result type.

Argument

A function may have arguments for interpretation. In signatures, you can use the type any. If so, in the function, this argument must have a stricter type. If a type is specified in the signature, the function can use the value.

Function

For each signature, we create at least one function. The purpose of functions is to interpret incoming information and make assertions. From the signature, we know the argument and result types, but in functions, the type any is no longer allowed and must be specified for each clause. The function establishes the relationship between the precondition and the postcondition. The name of this relationship or interpretation should be the function’s name.

Assertion

For each function, we need to create assertions that will allow us to understand the function’s meaning and test it. Each assertion contains specific values for arguments and the result according to the fact being tested.

The basis of the umwelt is the mindmap—a tree of concepts that contains assertions about social actions or facts. In the interpretation of fact theory, a fact is a statement made within a conceptual framework. Our task is to build a program that will make these statements, informing us about the facts. Here we arrive at functions and remember Hoare triples.

Specifications from Facts

Just as action is the core concept in sociology, and facts are the primary result, in programming, the core concept is the function and its result. Let’s examine the process of obtaining a function from a fact, or translating from the language of concepts and facts to automatically generate the program’s specification in the form of tests.

Since I chose Elixir to implement the umwelt, we will write the tests in the format of ExUnit, the standard testing framework in the Elixir ecosystem. However, you could just as easily do the same in Ruby using minitest/rspec, for example.

To describe these functions, we take the facts and use them to draft the program’s specification. As we established earlier, a fact is a statement of the form “bar is baz“, where bar (subject) is assigned the characteristic baz (predicate) via the mediator foo in the context of the concept Foobar, or assert Foobar.foo(bar) == baz.

Now we know what function and where to create it so that the test passes.

umwelt elements concepts fact programming