Type handling
This page describes how Simple Issue Language (SIL™) determines valid types during operations and manages type conversions.
Type handling
SIL uses a left-hand side (LHS) driven type system for operations. This means that:
The type of the left operand (LHS) determines how the operation behaves.
Operations only proceed under two conditions:
The right-hand side (RHS) type is already valid for the operation.
The RHS type can be converted to a valid type.
Type conversion, when needed, only applies to the right operand (RHS); the left operand never changes type.
Each operator in SIL has its own set of rules depending on the LHS type. These rules are defined using two lists:
Valid types list | Types that can be used directly with the operator. The operators tables in the Operatros reference show the relationships between operators, types, and their valid combinations. |
Convertible types list | Types that can be converted into one of the valid types. For details, see the Type Conversion topic. |
Think of it like this:
Valid types are like having the right key for a lock; they work immediately without modification.
Convertible types are like having a key that needs some reshaping before use - they require a transformation but can still work
Any other type is like having the wrong key entirely - the operation cannot proceed.
The "lock" (operation) is always determined by the LHS type.
This system helps prevent unexpected type conversions and makes code behavior more predictable. The type conversion rules are consistent across all operators. The reference tables on this page show these relationships in detail, specifying which types are valid for each operator and what conversions are possible.
Type resolution
When evaluating an operation, SIL follows this three-step type resolution process:
Step 1: | If the RHS type is valid for the operation, it proceeds immediately. The result is calculated as described in the operator table. |
---|---|
Step 2: | When SIL encounters a convertible type on the right-hand side (RHS), it tries to convert it to valid types in the same order that valid types are listed in the Operatros reference tables. This is important because it determines which type conversion is attempted first. See Type conversion example below. |
Step 3: | If the RHS type is neither valid nor convertible, the program stops with an error. |
Type conversion example
Here’s a practical example for the +
operator with LHS type number
.
// Valid types (in order):
// 1. number
// 2. integer
number x = 10.5; // LHS is number
x += "42"; // RHS is string (a convertible type)
//The attempted operation is to add 42 to x and assign the new value to x.
Here’s what happens:
The conversion attempt follows the order of valid types:
First, it tries to convert
string
(“42”) to anumber
and succeeds.Conversion stops at first successful attempt (
number
); no further conversion is attempted.
If the first conversion failed, it would try the next valid type (integer
). If the second conversion is successful, the operation is carried out.
Next, it carries the actual operation and adds 42 to 10.5.
If you ask for a return value, it will show 52.5.runnerLog("After adding \"42\": " + x); // Prints result: After adding "42": 52.5
This ordered approach ensures consistent and predictable type conversion behavior in all SIL operations.
Automatic type conversion
Type conversion in SIL enables variables of different types to be automatically converted when using the assignment (=) operator. This conversion process happens when you assign a value of one type to a variable of another type. When you make such an assignment, the system automatically attempts to convert the source value into a format that matches the target type while keeping its original meaning. For example, when converting a number to an integer, the system preserves the basic numeric value while adapting it to fit integer requirements. To learn more, see Type conversion.