To test that a property has a different value, use ~ as a prefix on the value. In the following rule, the second condition chunk the ~ prefix is used with a variable to ensure that this rule won't apply if the from and to properties have the same value.
# count up one at a time
count {@module goal; state counting; from ?num1; to ?num2},
count {@module goal; state counting; from ?num1; to ~?num1},
increment {@module facts; number ?num1; successor ?num3}
=>
count {@module goal; @do update; from ?num3},
increment {@module facts; @do get; number ?num3},
console {@module output; @do log; value ?num3}
You can also test that a given property is undefined by using ~ for the value on its own. This can also be used in action chunks when you want to set properties to be undefined .
Sometimes it may be necessary to test whether a variable holds a boolean, number, name, date, or string literal. This suggests the need for properties like @boolean, @number, @name, @date, and @string that test that their values have the given type.
Complex string operations would seem to be beyond the scope of a simple rule language, and something that could be better handled via invoking operations implemented by a module. This suggests that we don't need built in operators for string literals.
There is also a need for simple numerical operations, e.g. comparisons, such as @lteq which would be used with two variables to test that the value of the first is less than or equal to the value of the second. Likewise, @gt tests that the first value is greater than the second. Both tests fail if there is only one value, or more than two, or when either of the two values is not a number.
Note that @gt and @lteq involve the use of a comma separated list of values. That isn't supported in the minimalist version of chunks which limits properties to names. An alternative is to use an application defined action that passes the values as separate properties.
To test that a property has a different value, use
~as a prefix on the value. In the following rule, the second condition chunk the ~ prefix is used with a variable to ensure that this rule won't apply if the from and to properties have the same value.You can also test that a given property is undefined by using
~for the value on its own. This can also be used in action chunks when you want to set properties to be undefined .Sometimes it may be necessary to test whether a variable holds a boolean, number, name, date, or string literal. This suggests the need for properties like @boolean, @number, @name, @date, and @string that test that their values have the given type.
Complex string operations would seem to be beyond the scope of a simple rule language, and something that could be better handled via invoking operations implemented by a module. This suggests that we don't need built in operators for string literals.
There is also a need for simple numerical operations, e.g. comparisons, such as @lteq which would be used with two variables to test that the value of the first is less than or equal to the value of the second. Likewise, @gt tests that the first value is greater than the second. Both tests fail if there is only one value, or more than two, or when either of the two values is not a number.
Note that @gt and @lteq involve the use of a comma separated list of values. That isn't supported in the minimalist version of chunks which limits properties to names. An alternative is to use an application defined action that passes the values as separate properties.