A Kira Tour

A compact pass through entrypoints, imports, types, constructs, and execution annotations using repo-proven syntax.

This tour shows the current Kira language through the kinds of files the repo already proves.

A Small Entrypoint

Kira programs pick their entrypoint with @Main:

@Main
function main() {
    let left = 40;
    let right = 2;
    let total = left + right;
    print(total);
    return;
}

The current corpus proves this style across vm, llvm, and hybrid.

Imports and Helper Functions

Imports use qualified names and can declare an alias:

import support as Support

@Main
function main() {
    helper();
    print("imports resolve");
    return;
}

function helper() {
    let first = 1;
    let second = 2;
    print(first + second);
    return;
}

This is the same import shape used by the runnable import corpus and by namespaced bindings such as bindings.callbacks.

Named Types and Members

Kira uses struct for value-oriented data shapes and class for behavior:

struct RevenueSnapshot {
    let monthLabel: String
    let gross: Int
    let net: Int
}

class StoryLane {
    let width: Float
    let height: Float

    function area() -> Float {
        return width * height
    }
}

Fields and defaults appear in structs; methods appear in classes.

Typed Declarations

Kira local declarations now use an explicit three-form model:

var title = "Launch"
var pendingTitle: String
var opacity: Float = 0.8

That means:

  • inferred declaration from an initializer expression
  • explicit typed declaration with no initializer expression yet
  • explicit typed declaration with a strict initializer match

For example, var opacity: Float = 0.0 is valid, while var opacity: Float = 0 is rejected.

Constructs and Builder-Style Forms

The frontend also understands construct-defined declaration forms:

construct Widget {
    annotations {
        @State;
    }

    requires {
        content;
    }

    lifecycle {
        onAppear() {}
    }
}

Widget Card(title: String) {
    @State
    let selected: Int = 0;

    content {
        "Card"
    }

    onAppear() {
        return;
    }
}

This is check-only language coverage today, but it is real compiler behavior: the parser models it and semantics validates content requirements and lifecycle hooks.

The same builder-style surface now works especially well for C-layout FFI descriptors because @FFI.Struct { layout: c; } construction starts from zeroed storage before applying the listed fields.

Execution Annotations

Execution annotations matter when a program crosses runtime and native boundaries:

@Main
@Native
function main() {
    print("native main");
    runtime_helper();
    return;
}

@Runtime
function runtime_helper() {
    print("runtime helper");
    return;
}

Use the Language Guide for the full walkthrough, then keep the Language Reference nearby when you need precise rules.

On this page