Declaration

Source: reference-book. Raw markdown: /raw/docs/reference-book/4-dataflows/declaration.md

Declaration operator <<<$>>> is used when we want to declare a new variable. A variable is representing a specific flow of data. One can see variable declaration as creating a pipeline that is not anonymous anymore.

The only difference between <<<$>>> and simple <<<:>>> operator is that <<<$>>> marks the next token as a variable identifier. This is a compile time check and compiler makes sure variable declaration rules are applied. Variable definition will be done at runtime.

<<<$>>> helps to make variable declaration explicit and helps identify variable declarations.

It is important to remember that variables should always be declared before their usage. We will discuss the topic of scope in the next chapter whilst discussing the <<<wrapper>>> shells.

A valid variable declaration includes fulfilling the following conditions,

  • It starts with an alphabetic character, upper/lower case.
  • The only special character valid to be used in a variable name is <<<_>>> character.
  • A variable name may include numbers but not in the beginning of the name.
  • The identifier or name is unique in the scope.

Names like <<<myVariable>>>, <<<my_variable>>>, <<<myVar>>>, <<<myVariable1>>>, <<<myVariable_1>>> are valid and <<<1variable>>>, <<<variable@>>>, <<<123>>> are considered invalid.

Prefix and Suffix

It's a good time to discuss the two important concepts:

  • Prefix: Any specific expression coming before variable declaration operator <<<$>>> is considered a <<<prefix>>>. All these operations should be considered part of the essence of this new variable.
  • Suffix: Any specific expression coming after the identifier is considered a <<<suffix>>>.

Both prefix and suffix expressions are part of the essence of the variable.

Let's consider a simple example,

% 3 $var ?
100 var 

In the above example <<<var>>> is benefiting from a prefix expression <<<% 3>>> and a suffix <<?>>>. Now this variable has a specific behavior as part of its declaration.

""" sim -f var.art """ 1 !!!!

Now, it's nice that we have a variable that has two extra behaviors encoded in its essence. It always holds the result of a %3 and logs its value.

There are valid cases where a variable may have a specific characteristic that needs to happen but is not part of the value it represents. These cases are more like a side effect of vibration which can continue the processing. We will see useful patterns later in the <<<common-patterns>>> section that benefit from this behavior. Suffixes are exactly for this purpose.

As soon as the identifier vibrates, its value is received in the initial caller pipeline and the <<<suffix>>> logic continues running in the background.

A combined use of <<<prefix>>> and <<<suffix>>> shines when we have complex data structures, for example similar to objects in CPLs. So we can define complex objects by combining declaration statements and gates.

For example, let's define a <<<point>>> object in a 3D space that has three fields of <<<x>>>, <<<y>>>, <<<z>>> and its <<<z>>> value is always <<<0>>>. We know that a point in 3D space is valid only if all three fields have value. To force this business logic we will use an <<<AND>>> gate. Also, each of the values should be valid at any time. So the concept of <<<point>>> can be achieved only if all three fields of <<<x>>>, <<<y>>>, and <<<z>>> are getting their values, hence making it a <<<suffix>>> for our gate.

Considering all these conditions, the following declaration will fulfill our requirements,

($x, $y, 0 $z) $point

// Setting values
1 point.x
2 point.y


// will vibrate as soon as point.x is receiving its value
point.x ? 

// will vibrate only after all the fields are available
point ? 

""" sim -f point.art """ 1 (x: 1, y: 2, z: 0) !!!!

What we will see in the console consists of two logs, an object and a single value of <<<1>>> representing the <<<x>>>.

Using <<<Layer operator .>>> we can dig deeper into fields under <<<point>>> and get their value. More details about this operator will be shared in the next chapter.

As we can see the behavior of <<<point>>> is quite dependent on <<<x>>>, <<<y>>>, and <<<z>>> while <<<x>>>, <<<y>>>, and <<<z>>> have their own logic and they are not even aware that there is a higher logic dependent on them.

As another example, the following snippet shows a typical declaration of a boolean shell.

:[ & 1, !& 0 ] $boolean

$$$AlertBox type=HINT title=More Advanced Use Cases message=There are valid cases where a declaration needs more complex prefix and suffix logic. We will get back to these use cases in a future chapter of Wrapper Shells.$$$