Skip to main content
Kairo source files use the .ak extension and are organized into modules. Every file declares exactly one module, followed by imports, followed by declarations. There are no hidden ordering rules, no wildcard imports, and no ambient globals.

File shape

Every .ak file follows the same structure:
1

Module declaration

Must be the first non-comment line. One module per file.
2

Imports

Zero or more import, import ... as, or import type statements.
3

Declarations

Types, functions, and members that make up the file’s contribution to the module.

Module declarations

The module keyword declares the logical module a file belongs to. Module names use PascalCase segments separated by dots.
The module declaration is authoritative. Studio and Forge may warn when file paths do not match module names, but paths never override the declared identity.
Rules:
  • Exactly one module declaration per file.
  • Must appear before any imports or declarations.
  • Segments use PascalCase; the full name uses dot separators.

Imports

Kairo has three import forms, all explicit. There are no wildcards.

Module import

import Astra.Data

Alias import

import Astra.Net.Http as Http

Type import

import type Astra.Data.Database
Use import type when the file only needs a specific type. It removes any ambiguity between module names and type names for Forge and for readers.

Visibility

Every declaration has a visibility. internal is the default.

Comments

Kairo supports single-line comments with //. Block comments and doc comments are deferred.

Identifiers and casing conventions

Kairo follows consistent casing rules so readers can tell what a name refers to at a glance.

Statements and blocks

Kairo uses curly braces for all block scopes: function bodies, if/else, match arms, and type declarations. Statements do not require semicolons.

Next steps

Type system

Values, objects, contracts, enums, and how nullability works.

How Kairo Works

A developer tour of every language construct.