Mutation

The final aspect worthy of discussion is how mutation and object identity works in "imperative contexts" of Elara. These contexts appear in Elara functions and processes created by FunctionBuilder and ProcessBuilder.

Imperative programming in Elara functions and processes

Both FunctionBuilder and ProcessBuilder provide an imperative programming environment. This works be extending East expressions with a statement-based language. Both builders include statements for defining and reassigning variables, branching, looping, logging and raising errors. The semantics of this language works out quite similarly to JavaScript.

The special statements .insert, .update and .delete are also provided, with the purpose of mutating East collections (arrays, sets and dictionaries). Note that the other East types remain as immutable values. Structs, variants, strings and blobs cannot be modified.

The imperative programming environment is provided so users can express logic in a way they are used to. Mutation in particular unlocks powerful algorithms that may be easier to write and more efficient to execute than the equivalent logic written pure East expressions. East expressions are total and functional, which means they always terminate (they do not loop forever) and are not, in fact, Turing complete. On the other hand, the imperative environment for functions and processes featuring loops and mutation is Turing-complete and you can express a wider range of programs.

Evaluation semantics and object identity

East expressions are evaluated in a strict manner (not lazily, like Haskell). You can rely on expressions being evaluated as if it were performed as a straightforward depth-first traversal of the AST (abstract syntax tree). When code branches, only the relevant branch is evaluated. Values are not usually "copied" unexpectedly. While many East expressions will construct and return a new value, expressions like Let, Get, GetField, IfNull and Match will not perform any copying. They will produce references to existing objects instead.

Object identity works as it does in popular imperative languages such as JavaScript. When an array is constructed, for example, it is allocated some space in memory and the object is referenced by pointer. The same reference is used when the array is assigned to a variable, placed inside another data structure, etc. When the array is mutated by .insert, .update or .delete statements it appears modified in all the places the reference exists. (And when a new array is created by Insert, Update or Delete expressions, the output does not alias any mutable memory from the original array).

In the end, Elara's statement-based imperative language maps reasonably closely to TypeScript and JavaScript. It is usually possible to reason about the code produced by FunctionBuilder and ProcessBuilder by imagining the equivalent JavaScript function. The main distinctive feature is that "side effects" like variable reassignment, mutation of collections, and logging occur as statements, and are not possible inside expressions.

East does not provide an expression to determine if two objects have the same identity (like Object.is in JavaScript). If you find you rely on such details in order to implement your logic correctly, you might want to reconsider your approach. When the identity of objects is not obvious, your code will be hard to reason about and difficult to maintain. You can often refactor into a more straightforward or "functional" approach that is just as performant.

Next steps

Congratulations! You have completed the guide to East. This knowledge should enable you to model complex data and craft powerful logic for your Elara solutions.