Section 2: Type System¶

TECHSPEC-02 — Section 2 · Version 0.1 · Status: Initial Draft

Status: draft. This section is an Initial Draft (Section 57 is a Working Register). It describes intended or proposed behavior, not a finalized, implemented language rule. Do not treat examples here as normative.

1. Type System Philosophy¶

The language uses a strict, statically checked type system.

Every value must have a known type before compilation.

The type system must prevent invalid operations, unsafe conversions, and ambiguous data handling.

2. Primitive Types¶

The initial language supports the following primitive types:

3. Composite Types¶

3.1 Struct¶

Structs define objects containing explicitly typed fields.

TYPE Account:
    id: Integer
    balance: Decimal
    active: Boolean

Every field must have a declared type.

3.2 Enum¶

Enums define a fixed set of possible values.

ENUM AccountStatus:
    ACTIVE
    SUSPENDED
    CLOSED

Values outside the declared set are invalid.

3.3 Collections¶

The initial version supports:

• List: Ordered collection of values of one declared type.
• Map: Key-value collection with explicitly declared key and value types.
• Tuple: Fixed collection of explicitly typed values.

Examples:

users: List<String>
scores: Map<String, Integer>
coordinates: Tuple<Decimal, Decimal>

4. Safety Types¶

4.1 Optional¶

Represents a value that may be absent.

email: Optional<String>

The compiler must require the absence case to be handled before accessing the contained value.

4.2 Result¶

Represents either successful execution or a declared failure.

Result<Integer, CalculationError>

A Result must explicitly represent success or failure.

4.3 Constrained Types¶

Types may include additional requirements.

TYPE PositiveAmount = Decimal
    WHERE VALUE > 0

The compiler must enforce constraints statically when possible and use runtime checks when necessary.

5. Type Safety Rules¶

1. All variables must have declared types.
2. Function arguments must match their declared parameter types.
3. Return values must match declared return types.
4. Implicit type conversions are prohibited.
5. Potentially absent values cannot be accessed without handling absence.
6. Invalid operations between incompatible types must be rejected.
7. Collection contents must match their declared types.
8. Enum values must belong to their declared enum.
9. Constrained types must satisfy their declared requirements.
10. Unsafe type conversions must require explicit syntax and appropriate checks.

6. Type Inference¶

Type inference is permitted for intermediate expressions when the compiler can determine exactly one type.

Variable declarations must always explicitly declare their types.

The compiler must never silently resolve ambiguous expressions by guessing.

7. Compiler Responsibilities¶

The compiler must:

• Resolve every expression's type.
• Validate function signatures.
• Detect incompatible operations.
• Enforce constrained types.
• Detect unsafe conversions.
• Validate Optional and Result handling.
• Produce structured diagnostics identifying type violations.

8. Design Goal¶

Types must communicate both the structure of data and the guarantees that can safely be assumed about it.

The compiler must reject programs that violate those guarantees rather than relying on the AI agent to recognize its own mistakes.

Source and related sections¶

Source file: TECHSPEC-2.md (preserved in source-original/LANG/). See the specification index, the glossary, and the cross-reference index.