Skip to content
DocumentationNative One
On this page

Page resources

Open Markdownllms.txtView source

Last updated

Native One

Native One is the small executable language for semantics-shaped connective code. Use it when an operation mainly constructs owned values, matches typed outcomes, sequences operations, and handles effects or uncertainty already defined by the selected semantic closure.

It is not a general-purpose replacement for Rust or ecosystem languages. General algorithms, numerical kernels, provider SDKs, low-level concurrency, arbitrary I/O, FFI, and library-heavy behavior belong behind an owned contract in another exact implementation profile.

Implement one exact operation

A Native One body remains an isolated implementation item. The header names the claim, realized contract, and exact profile; the indented source suite is untrusted executable source:

impl example.hello#HelloServiceOne@1
    realizes example.hello#Greeter.SayHello@1
    using one.language.one#SafeAsync@1
    source
        async SayHello(request: HelloRequest)
        -> Result<Greeting, GreetingDomainFault>
        {
            ok(Greeting {
                message: text("Hello, ", request.name, "!")
            })
        }

The realized interface supplies the expected operation name, input, result, faults, effects, and capabilities. Do not repeat it through a wrapper, language-local service declaration, or generic entry point. Names visible in the body come from the exact Native One projection of the locked semantic closure, not from workspace text search.

Understand the execution model

The SafeAsync@1 grammar admits only bounded forms for:

  • nominal value construction and field access;
  • matching, sequencing, typed results, and declared faults;
  • exact operation calls and selected state access;
  • cancellation and unknown-outcome handling; and
  • compensation and reconciliation where the contract requires them.

Semantic packages add types, operations, states, faults, effects, capabilities, and invariants to that vocabulary; they never add grammar or ambient runtime powers. Network, filesystem, environment, process, clock, entropy, credentials, and state access exist only when an exact requirement, grant, and selected host/provider boundary supplies them.

Check before realization

one check --root hello
one inspect example.hello#HelloServiceOne@1
one test --root hello
one invoke example.hello#Greeter.SayHello@1 request.json

Checking parses and type/effect-checks the exact logical body in a capability-empty analyzer and retains its analysis receipt. That receipt does not prove compilation, selection, an artifact, a runtime binding, or authority. Planning selects an eligible realization; Build binds the exact body, dependency closure, language definition, frontend, toolchain, target, and artifact; invocation still requires the applicable runtime grant.

Native One can be realized as checked bytecode or as a WebAssembly Component when the selected root and provider support that boundary. Both preserve the same contract and evidence path; repository package presence activates neither.

Next: add other implementation languages or check, test, and invoke.