Foundation Modules

Packages and Imports

Klyn keeps import rules deliberately strict so that name resolution stays predictable and fast. The language distinguishes clearly between packages, types, and fully qualified names.

What Is Imported by Default

Only the base package klyn is imported automatically. This gives immediate access to core language types and helpers, but not to subpackages such as klyn.math or klyn.collections.

# Works because klyn is implicit
value as Int = 10

# Requires an explicit import
import klyn.math
r = Rational(1, 3)

Declaring a Package

A package declaration belongs at the top of the file and must match the folder layout.

package my.app.core

public class User:
    pass

The file must live under my/app/core/User.kn if User is the public class declared in that file.

Import Rules

Rule	Meaning
Import packages, not types	`import klyn.math` is valid. Importing `klyn.math.Rational` directly is not.
Imports are module-level only	Do not place an import inside a function, method, or class body.
Fully qualified access remains available	You can always write `klyn.math.Rational(1, 3)` when you want a precise name.

Using Fully Qualified Names

Qualified access is useful when two packages expose similarly named types or when you want to keep a script explicit without adding an import.

r = klyn.math.Rational(1, 3)
assert r.numerator == 1
assert r.denominator == 3

What Not to Do

These patterns are rejected

def build():
    import klyn.math      # invalid: import inside a function

import klyn.math.Rational # invalid: importing a type directly

Organizing Files Cleanly

Use one public class per file.
Keep the file name identical to that public class.
Keep the package path aligned with the folder path.
Prefer explicit imports over ambiguous name resolution.

Next Step

Continue with Typing and Constants to understand the static typing rules that drive the rest of the language.