Language

Kyllo is a statically typed language in which requirements are written into the program and checked. This page summarises the design as documented in the specification (v0.1 Initial Draft). Every feature carries a status label — Accepted, Proposed, or Unresolved — because the specification is a draft, and presenting a proposal as settled would be a false claim.

The authoritative reference is the Language Guide and the Technical Specification. This page does not replace them.

Type system Proposed

Kyllo is strictly and statically typed. There are no implicit conversions: a value of one type is never silently treated as another. Type inference is proposed only for intermediate expressions — never for variable declarations, which must state their type.

• Primitive types: Integer, Decimal, Boolean, String, Character, Unit.
• Composite types: Struct, Enum, and collections — List, Map, Tuple.
• Wrapper types: Optional (a value that may be absent) and Result (a value or a failure — see below).

Status: the type system is described in the Initial Draft and is proposed, not accepted. Details — including the exact collection semantics — remain open to decision.

Numeric semantics

Integer Proposed

The integer half is effectively decided in the draft: signed 64-bit, range −9,223,372,036,854,775,808 to 9,223,372,036,854,775,807, with checked arithmetic. Overflow, underflow, and division by zero are explicit failures — there is no silent wrapping.

Decimal Unresolved — OQ-002 open

The decimal half is unresolved. The draft says “decimal128-compatible”, but that phrase names no standard: no IEEE or General Decimal Arithmetic conformance target is established, the exponent range is asserted but never given, there is no defined Decimal literal format, and whether 1.50 == 1.5 is undecided. There is no NaN or Infinity anywhere in the specification, and the outcome of Decimal overflow or division by zero is unspecified.

A proposal to adopt General Decimal Arithmetic v1.70 (precision 34, round-half-even, Emin −6143, Emax 6144) exists as a decision-preparation report. It is proposal only — it has not been accepted, and this site does not present it as adopted. Decimal conformance, integer division and remainder (OQ-003), and rounding context (OQ-004) are open questions.

Variables and declarations Proposed

Declarations state their type explicitly. Three declaration kinds are proposed:

• LET — immutable: the value cannot be changed after it is bound.
• VAR — mutable: the value may be changed.
• CONST — compile-time constant.

Example — Accepted OQ-001 (statement termination)

LET balance: Decimal = 100.00;
CONST MAX_RETRIES: Integer = 5;
balance = balance + 25.00;
PRINT(balance);
RETURN balance;

Simple statements and declarations end with a semicolon. That rule is accepted (OQ-001); the declaration kinds themselves are proposed.

Functions and modules Proposed

Functions must declare their inputs and outputs, their contracts (below), and their implementation. Modules are private by default, and dependencies between modules are explicit and versioned. A function signature is a promise: what goes in, what comes out, what it requires, and how it can fail.

Example — Accepted OQ-001 (typed block terminators)

FUNCTION calculate() -> Integer
    RETURN 42;
END FUNCTION;

Compound structures end with a typed terminator that matches the opening structure. There is no redundant semicolon after a terminator: END FUNCTION;; is rejected. A generic END; is rejected.

Contracts Proposed

Contracts are declarations attached to functions and types:

• REQUIRES — preconditions the caller must satisfy.
• ENSURES — postconditions the function guarantees, which may refer to the old value with OLD(...).
• INVARIANT — a condition that must hold throughout.
• EFFECTS — what the function changes.

The effect taxonomy is not settled — the draft's effect vocabulary is still open. Contracts are proposed, not accepted, and how far they can be checked statically versus at runtime is part of the verification design (see Verification).

Results and errors Proposed

Operations that can fail must return a Result. Failures cannot be silently ignored: the caller must handle the failure case explicitly. This is the mechanism that makes “no assumed success” concrete — a program cannot proceed as if an operation that might fail had succeeded.

One honest caveat: the Result vocabulary is not canonical across the docs — some examples write SUCCESS/FAILURE and others SUCCESS/ERROR. Until that is reconciled, examples on this site keep the vocabulary of their source and say so.

Expressions and operators Proposed

Arithmetic (+, -, *, /, %), comparison, and logical operators (AND, OR, NOT) with short-circuit evaluation. Chained comparisons are not allowed. Operator precedence in the draft is an initial proposal, not a final decision.

Compile-time evaluation Proposed

CONST declarations and literals are evaluated at compile time. In the MVP scope, compile-time evaluation covers literals and simple deterministic expressions only. Broader compile-time execution is not part of the initial scope.

Examples

All examples below are copied from the documentation. Their source and status are stated with each one. Nothing here is compiler output — there is no compiler yet.

Simple statements — Accepted OQ-001 · source: decision record OQ-001

LET balance: Decimal = 100.00;
CONST MAX_RETRIES: Integer = 5;
balance = balance + 25.00;
PRINT(balance);
RETURN balance;

Blocks — Accepted OQ-001 · source: decision record OQ-001

IF balance > 0:
    PRINT(balance);
ELSE:
    PRINT(0);
END IF;

WHILE balance > 0:
    balance = balance - 1;
END WHILE;

Semicolons after simple statements; typed END terminators; no redundant semicolon after a terminator; generic END; rejected.

Bank Account deposit — Tutorial, not normative · Proposed

FUNCTION deposit(account: Account, amount: Decimal) -> Result<Account, DepositError>
    REQUIRES: amount > 0;
    ENSURES: result.balance == OLD(account.balance) + amount;
    EFFECTS: MODIFY account.balance;
    FAILURES: InvalidAmount;
    IMPLEMENTATION:
        account.balance = account.balance + amount;
        RETURN SUCCESS(account);
END FUNCTION;

Known inconsistency, stated openly: the documentation contradicts itself on the postcondition subject — result.balance here versus SUCCESS.balance in TECHSPEC-03. That contradiction is documented in the audit (AUDIT-014) and is unresolved. Do not treat this example as settled syntax.

Type declaration — Proposed

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

Divide — Proposed · vocabulary contested

FUNCTION divide(a: Integer, b: Integer) -> Result<Integer, DivisionError>
    REQUIRES: b != 0;
    IMPLEMENTATION:
        RETURN SUCCESS(a / b);
END FUNCTION;

This example uses SUCCESS/ERROR vocabulary; other examples use SUCCESS/FAILURE. The vocabulary is not yet canonical.