Asserts, Math, if, Sub-Commands, ?, and !

SOP Lang Pipeline includes a set of expression-oriented primitives that define boolean or numeric variables directly, and conditional constructs that preserve the reactive properties of the language.

assert Expressions

In SOP Lang Pipeline, the assert command defines a variable that holds the boolean result of an expression. Its syntax is @booleanVariable assert boolean_expression.

@temperature := 22
@isGoodWeather assert $temperature > 20

# If @temperature changes to 15, @isGoodWeather updates to false.

The primary necessity for a command that evaluates directly to true or false lies in establishing a clear foundation for conditional operations. By using assert to create named boolean variables, condition logic is separated from decision logic.

Complex conditions follow JavaScript operator semantics. In the current parser constraints, spacing around parentheses is recommended for robust tokenisation. As these expressions are evaluated through JavaScript semantics, robust sanitisation of input values remains a runtime concern.

@tmpC := 23
@isSunny := true
@isWeekend := false
@goodForPicnic assert ( ( $tmpC > 20 && $tmpC < 28 ) || $isWeekend ) && ( $isSunny == true )

math Expressions

In SOP Lang Pipeline, the math command defines a variable that holds the numeric result of a mathematical expression. Its syntax is @numericVariable math numerical_expression.

@length := 10
@width := 5
@area math $length * $width

# @area => 50

Like assert, this command is reactive and recalculates when dependencies change. SOP Lang Pipeline's math command supports standard JavaScript mathematical operators and parenthesised grouping.

@itemPrice := 75
@quantity := 2
@discountPercentage := 10
@taxRate := 0.08

@subTotal math $itemPrice * $quantity
@discountAmount math $subTotal * ( $discountPercentage / 100 )
@priceAfterDiscount math $subTotal - $discountAmount
@taxAmount math $priceAfterDiscount * $taxRate
@totalCost math $priceAfterDiscount + $taxAmount

If any prerequisite variable changes, all dependent math variables are recomputed automatically in graph order.

Conditional Execution with if

@userAge := 22
@isAdult assert $userAge >= 18
@accessMessage if $isAdult then "Welcome! Full access granted." else "Access restricted."
@accessCode if $isAdult then 1000 else 4001
@systemStatus if true then "System Active" else "System Offline"

The syntax for if is @output if condition then valueIfTrue else valueIfFalse. The command is reactive: when dependencies in condition or selected branch change, the output is updated.

Conditions are typically boolean variables produced by assert, but literals and other values can be used as condition inputs according to their truthiness semantics.

Sub-Commands

Sub-commands are denoted by enclosing a command and its parameters within square brackets: [command parameters]. If a command is invoked without an explicitly declared output variable, the system automatically generates a temporary variable to hold the result.

These expressions are preprocessed and substituted before the outer command is evaluated. This allows concise composition for assertions, math, and nested command calls.

@userAge := 25
@minAge := 18
@accountBalance := 1500
@minBalance := 1000

@eligibilityStatus if [assert $userAge >= $minAge && $accountBalance >= $minBalance] then "Fully Eligible" else "Not Eligible"
@creditLimit if [assert $accountBalance > 2000] then [math $accountBalance * 2] else 500

@productName := "Gizmo"
@basePrice := 100
@taxRate := 0.07
@productReport assign "Product: " $productName ", Price with Tax: $" [math $basePrice + ( $basePrice * $taxRate )]

Conditional Execution with ?

In SOP Lang Pipeline, managing asynchronous data flow and undefined values is crucial, especially for commands with side effects. Prefixing a command with ? makes execution conditional on all direct inputs being defined and non-empty.

In the current runtime, this conditional marker is accepted as prefix and suffix for command names (?command and command?). For member calls, it is supported as object.?method.

@creditCardNumber
@expiryDate
@cvvCode
@amount := 100.00

@paymentStatus ?processPayment $creditCardNumber $expiryDate $cvvCode $amount
@confirmationMessage if [assert $paymentStatus == "SUCCESS"] then "Payment Confirmed!" else "Payment Pending or Failed"

If any guarded input is undefined at evaluation time, guarded execution is skipped and the output remains undefined until a future reactive pass where all required inputs are present.

This mechanism acts as a practical safeguard in dependency chains where values may be populated by user input, asynchronous system updates, or delayed computations.

Forced Execution with !

Forced execution is accepted with ! as both prefix and suffix (!command and command!). It forces evaluation on every build pass, even when the variable dependency clocks did not change. This is useful when command outputs depend on external state that is not visible in graph dependencies (for example filesystem polling or external script reload checks).

@watcher new Folder "./incoming"
@snapshot !watcher.newer "./incoming"
@scriptState !import "MyApp" "MainScript"

@counter jsdef
    if(globalThis.counter === undefined){
        globalThis.counter = 0
    }
    globalThis.counter++
    return globalThis.counter
end

@normal counter
@forced !counter
@forcedSuffix counter!

In this model, recomputation policy becomes explicit in script code: commands run reactively by default, and ! is the opt-in override for always-execute semantics.