Conditional

Now what happens if you want to have a shell that needs to be impacted by an external vibration. This is the exact use case of a <<<conditional>>> shell.

Emphasizing again, everything in Simorg is either vibration or a Shell that wraps the vibration. So for the rest of this document, we will refer to a conditional wrapper shell simply as conditional.

A conditional is an isolator shell but with a way to explicitly activate it. Let's see it in action,

1 {
  "Hello World!" ?
}

This is a super simple conditional shell. It is using an activator vibration (value literal <<<1>>>) to activate the shell.

As soon as activation vibrates, the internal shells can also do their vibration.

Now a more classical example of a conditional shell is of course an <<<If Statement>>>. Actually, it's due to these similarities that simorg is calling this category of wrapper shells a conditional wrapper shell.

100 $a
200 $b

(a > 50, b > 50) {
  "'a' and 'b' are greater than 50" ?
}

In this example we are using an <<<AND>>> gate to create a condition between both elements. In this case the shell will vibrate only if two conditions are met.

The following code is a classical representation of the same solution (C++ syntax),

#include <iostream>

int a = 100;
int b = 200;

if (a>50 && b>50) {
  std::cout<< "Both numbers are greater than 50"<< std::endl;
}

Apart from extra lines that are related to the way <<<C++>>> works, the main body of code is quite similar. Thanks to the concept of vibration and the new data-centric approach of simorg, the code is behaving naturally even without extra reserved keywords.

At this point mentioning a few points seems useful:

• It's totally valid to use any kind of expressions to activate a Shell including variables, dataflows, calculations, gates, etc.
• Simorg doesn't have an <<<else>>> statement. This was touched on briefly in the dataflow chapter while discussing the truthy operator. This is due to the way the engine works. Our code is creating channels in which the data will be streamed. This also has roots in how our nature works. If something happens it is a pure result of the existence of necessary conditions, not because of the non-existence of a series of other conditions. This also helps writing code that is less error-prone.

It's even possible to do variable declaration as part of a <<<Wrapper Shell>>> statement. This gives us two possibilities.

• Having named Wrapper Shells which are variables plus a dedicated space to them to implement their own advanced logic, which we will discuss in the next section on io shells.
• Receiving external data and use it inside the shell.

$externalData {
  externalData ?
}
"External Vibration" externalData

$myVar {
  "Dedicated space to implement a complex suffix" ?
}
"External Vibration" myVar

$$$AlertBox type=HINT title=Shells As Spaces message=The condition of a wrapper shell can be seen as a hole that external vibrations are able to pass through it into the shell.$$$

$$$AlertBox type=HINT title=Let's Embrace Simplicity message=If the side effect of the codition is limited to one single action, it's best to avoid using wrapper shell as the code will become much cleaner.$$$

Let's now move forward with the final category of wrapper shells, the <<<io>>> shells.