Speak in meaning. Think beyond syntax. Built beyond language.
Documentation
Semantic

Create a Module.

A Semantic module is a portable ZIP archive containing its files and a .smod manifest. Semantic is UAST-derived and built to carry meaning across language boundaries, so modules can represent and import functionality originating in different programming languages. Host the archive wherever you want; the registry stores only the module name and the release URL.

1. Module structure

Keep the archive self-contained. A typical module looks like this:

my-module/ ├── module.smod ├── src/ │ ├── module.semantic │ └── helpers.semantic ├── README.md ├── LICENSE.md └── icon.ico # optional

The .smod file is required and describes the module and the files that belong to it. README and license files are strongly recommended. For automatic recognition, use README.md or README.txt, and LICENSE.md or LICENSE.txt. An .ico file is optional and can be displayed as the module icon.

2. Create the .smod manifest

The easiest path is to generate the manifest with the Code Transpiler CLI or the Go tooling rather than writing it by hand. The manifest should at minimum carry the module identity, version and the module files. Keep the module name stable across releases.

# Conceptual example — adapt to the current CLI syntax codetranspiler import module ./my-module # The tool scans the module and creates / updates module.smod

The exact CLI command may evolve with the tooling. Keep the documentation in sync with the released Code Transpiler syntax.

3. Release the module

Zip the complete module directory and upload the archive to a public HTTPS location: a GitHub or GitLab release, your own website, or another file host. Semantic does not copy the archive into the registry.

my-module-v1.zip my-module-v2.zip my-module-v3.zip

For a new major release, keep the same module identity and use the same source path / host pattern while increasing the version suffix, for example -v2. The registry automation can then verify that the update belongs to the existing module rather than replacing it with an unrelated source.

4. Publish to the Semantic registry

Open Modules → Add Module, enter the module name and direct ZIP URL, and continue with GitHub. GitHub provides the publisher authentication. The registry workflow downloads the archive temporarily, verifies that it is a readable ZIP and that a .smod file exists, then updates modules.json.

The registry itself contains only:

[ { "name": "MyModule", "url": "https://example.com/MyModule-v2.zip" } ]

5. Install a module

There are three intended installation paths:

Code Transpiler CLI

Use the module import command to download, validate and place the module in the Semantic module store.

Go API

Applications using the Code Transpiler Go package can perform the same module import programmatically through the module tooling exposed by the package.

Open Go Reference ↗

Manual installation

Download the ZIP, extract it, inspect the .smod manifest and place the complete module directory into your configured Semantic module store. Do not omit files listed by the manifest.

6. Import a module

Semantic modules can be imported by name, local directory, ZIP archive or HTTPS URL. The importer checks the configured module store first and downloads the module only when it is not already available.

# Import by module name
codetranspiler module import tifffile

# Import a local directory
codetranspiler module import ./my-module

# Import a ZIP archive
codetranspiler module import ./my-module.zip

# Import from an HTTPS URL
codetranspiler module import https://example.com/my-module.zip

The archive is extracted, its .smod manifest is verified, and the module is stored in the configured Semantic module store. Existing modules are reused by semantic identity and are not imported twice.

When a Semantic program imports the module, the compiler resolves it from the local store and embeds only the required declarations unless full embedding is requested.

7. Remote content and privacy

Module archives are not stored on this website. When a module page is opened, the browser may request the external archive or repository in order to display its README, license and optional icon. The external host can therefore receive ordinary request data such as the visitor's IP address. See the Privacy Policy for details.