Local packages and the standard library

SOS supports local packages and standard-library operations. A module
is identified by a logical path in project sos.toml; packages are directories
of .sos source files. There is no package download service or remote dependency
resolver.

4 lines
version = 1[module]path = "example.com/support-tools"

For a reporting/ directory, import example.com/support-tools/reporting.
A source file can name its package, declare imports, and export actions:

7 lines
package reportingimport "std/text" as textexport summarizeto summarize with title:  call text.trim with title called clean  return clean

The entry script can call it:

3 lines
import "example.com/support-tools/reporting" as reportscall reports.summarize with "  Support queue  " called titleshow title

Package files share action declarations; imports belong to their defining file.
Private helper actions stay private to the package. Importing is declaration-only:
package-level executable statements are rejected. Package actions receive explicit
arguments and cannot capture their caller's variables. Their operations use the
calling run's configuration and budget; library frontmatter cannot raise limits.

The loader bounds graph depth and source size and rejects cycles. Native and WASM
artifacts carry the resolved source graph so local source files are not needed on
the destination machine. Existing single-file scripts remain supported.

Import vocabulary

In SOS 0.3, imports without as expose bare sentence words and preserve the
default qualified form. An explicit as requires the alias prefix. Exported
actions contribute their names; packages may add synonyms with word alias of action.
See vocabulary for configured imports and discovery.

Standard library

ImportActionInputResult
std/texttrimtexttext without surrounding Unicode whitespace
std/textuppertextuppercase text
std/textlowertextlowercase text
std/jsonencodeany supported valueJSON text
std/jsondecodeJSON textdecoded value; invalid JSON is an error
3 lines
import "std/text"call text.upper with "hello" called greetingshow greeting

These operations are pure: no filesystem, network, or model requests. Argument
counts and types are checked. They work with native, browser WASM, and WASI builds.
Broader filesystem, HTTP, process, time, and collection package APIs remain future
work; existing canonical sentences retain their behavior.

Go API

LoadProgram(filename, source) resolves a program and its local imports.
CheckFile(filename, source) checks with the same filesystem context.
LoadProgramFromGraph restores the embedded graph for standalone execution.
Program.ExportedOperations() describes imported exports.
StandardOperations() returns a detached, sorted catalog of executable standard
operations, including parameter types, result types, effects, and target support.
It reads the runtime registry, performs no I/O, and powers editor documentation
and completion.

See editor services for offline completion and auto-import.

Run the checked-in multi-file example with:

1 lines
bin/sos run examples/sos/packages/main.sos

In Studio, choose the library example to try colors, type hints, and standard
operations. Choose the project's working folder before using local package suggestions.

See library vocabulary and the searchable dictionary
for open imports, parent aliases, and project-wide library configuration.

Jev question values

std/jev supplies pure question constructors, named batch assembly and answer lookup. See question batches. Construction does not make provider requests; the canonical evaluate sentence does.

Host and collection libraries

See Files, streams and values for std/files, std/path,
std/io, std/process, std/list, std/record and expanded std/text operations.
Use parallel maps to process independent records with
bounded workers and ordered results. Host operations publish target restrictions
in the vocabulary catalog; subprocesses require a native target.