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.
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)
A package declaration belongs at the top of the file and must match the directory layout, with one directory per package segment.
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. The directory containing my is the source root.
A file without a package declaration belongs to the default package. Klyn never
infers a package from the file path, and an import never changes the current
package. For reusable libraries and multi-file applications, prefer named packages.
| Rule | Meaning |
|---|---|
| Import packages only | import klyn.math is valid. import klyn.math.Rational is rejected because Rational is a type, not a package. |
| Imports are module-level only | Do not place an import inside a function, method, or class body. |
| Imports do not declare the current package | import my.app.core only makes that package visible; the current file remains in its declared package or in the default package. |
| Fully qualified access remains available | You can always write klyn.math.Rational(1, 3) when you want a precise name. |
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
value = 10
import klyn.math # invalid: imports must stay at the beginning
import klyn.math.Rational # invalid: imports cannot target a type
def build():
import klyn.math # invalid: import inside a function
- Use one public top-level type per file.
- Keep the file name identical to that public type.
- Keep the package path aligned with the folder path.
- Do not rely on a directory name to infer a package.
- Prefer explicit imports over ambiguous name resolution.
Continue with Class Loading to understand where imported classes are searched and why the standard library always has priority.