Preparing Sekura JS for Open Source

AI Summary: Sekura JS is an internal systems programming language designed for the Sekura computing stack, together with Reganta OS and the Memora8 processor architecture. Its toolchain already supports explicit .sjs, .sasm, .sdef, .sobj, and .smod artifacts, module identities, runtime modules, function frames, and a defined runtime layout. Before the compiler becomes public, the project must separate it from private infrastructure, make builds reproducible, document the language and runtime ABI, stabilize the CLI, publish behavior-focused tests and examples, clean the repository, and choose a license and contribution model. The first open-source boundary will focus on the language, compiler, specification, tests, examples, build system, and documentation. The larger goal is an inspectable and increasingly verifiable path from source code through the compiler and Reganta OS to Memora8 execution.

Sekura JS started as an internal systems programming language for the Sekura computing stack.

It was designed together with Reganta OS and the Memora8 processor architecture, rather than as a general-purpose language intended to run everywhere.

That gave us freedom to make some unusual choices.

Sekura JS has its own module model, explicit runtime structures, predictable compilation artifacts, and a close relationship with the execution environment below it.

Until now, most of this work has remained internal.

We are preparing to change that.

Our goal is to make Sekura JS open source and turn the compiler, language specification, test suite, and examples into something that can be independently inspected, built, tested, and eventually extended.

This article describes what Sekura JS is today and what needs to happen before the repository becomes public.

What Sekura JS Is

Sekura JS is a systems programming language designed for the Sekura stack.

Its current compilation pipeline can be represented roughly as:

Sekura JS source
      ↓
     .sjs
      ↓
Sekura JS compiler
      ↓
 .sasm / .sdef
      ↓
     .sobj
      ↓
     .smod

A source file describes a module.

The compiler transforms that source into a set of artifacts representing assembly, interface information, object code, and a runtime-loadable module.

The language and toolchain are designed around an explicit execution model rather than around a large hidden runtime.

This matters because our long-term goal for Sekura is not merely to execute software.

It is to make the relationship between source code, generated code, operating system behavior, and processor execution increasingly understandable and verifiable.

Why Open Source Sekura JS

Programming languages make strong claims.

A compiler claims that it correctly translates one representation of a program into another.

A runtime claims that it executes that program according to defined rules.

An operating system claims that it correctly manages execution and resources.

A processor claims that it correctly performs the operations defined by its architecture.

Those claims become more interesting when they can be inspected.

For Sekura, open source is therefore not only a distribution model.

It is part of the engineering direction.

If Sekura JS is intended to become part of a verifiable computing stack, its compiler should not remain a black box.

Developers and researchers should be able to inspect the implementation, reproduce builds, examine generated code, test the language semantics, and challenge the assumptions behind the system.

Open sourcing Sekura JS is one step toward that goal.

What Already Exists

Sekura JS is not starting as an empty public-language project.

The internal implementation already includes a defined architecture for several important parts of the system.

Module Model

A Sekura JS source file represents a module.

Modules have an identity and a profile.

Current profiles include:

• runtime modules;
• system modules;
• library modules.

The distinction affects how a module is compiled and how it participates in the runtime environment.

Runtime modules can be transformed into executable .smod artifacts containing the information required by the loader and runtime.

Stable Module Identity

Sekura JS modules can use a stable RegID.

The RegID is not simply a filename or a temporary build identifier.

It is part of the identity of a runtime module and can be carried into the generated module representation.

This gives us a foundation for referring to software components independently of their current file location or build environment.

Explicit Compilation Artifacts

Instead of hiding the entire compilation process behind a single opaque binary, the current toolchain works with several explicit artifacts.

For example:

.sjs   source module
.sasm  generated assembly representation
.sdef  module/interface definition
.sobj  object representation
.smod  runtime module

These intermediate forms are useful during development because they make individual stages of compilation observable.

They can also become useful for testing and verification.

Function Frames and Local Variables

Sekura JS has an explicit model for local variables and function frames.

Local names have lexical scope, while the backend places local values into a function frame using defined frame offsets.

The generated code therefore has a direct and inspectable relationship with the compiler’s model of function state.

Runtime Layout

Executable modules follow a defined runtime layout.

The goal is to keep this layout simple enough that the boundary between compiler output and runtime execution can be documented precisely.

That boundary will become especially important as we formalize the public ABI between Sekura JS, Reganta OS, and Memora8.

What Is Not Ready Yet

Internal software and open-source software have very different requirements.

A compiler can work perfectly well for its original authors while still being difficult for an external developer to build, understand, or trust.

Before publishing Sekura JS, we want to address several areas.

1. Separate the Compiler from Internal Infrastructure

The public compiler must be able to build without depending on private development infrastructure.

That means identifying internal assumptions, paths, tools, libraries, and build steps that were convenient during development but should not become requirements for external users.

A fresh checkout should eventually be enough to build the compiler using documented dependencies and commands.

2. Make Builds Reproducible

A public compiler should behave predictably.

Given the same compiler version, source code, target, and options, developers should be able to understand why a particular output was produced.

Reproducible builds are important not only for convenience.

They are part of the path toward verification.

Before reasoning about whether a compiler produces correct code, we first need confidence that the compilation process itself is deterministic and repeatable where expected.

3. Define a Minimal Language Specification

An implementation alone is not a language specification.

Before the public release, we want to document the core behavior of Sekura JS independently from the compiler source.

The initial specification does not need to describe every possible future feature.

It needs to define the parts that already exist clearly enough that a developer can distinguish:

• intended language behavior;
• implementation details;
• undefined behavior;
• compiler bugs.

This includes syntax, types, modules, functions, variables, memory behavior, imports and exports, and the semantics of the core operations.

4. Stabilize the Command-Line Interface

Internal tooling often evolves organically.

Options are added for experiments, debugging, temporary targets, or specific development workflows.

A public compiler needs a smaller and more coherent interface.

The objective is not to expose every internal switch.

The objective is to make the common workflow obvious:

source
  ↓
compile
  ↓
inspect
  ↓
link/package
  ↓
run

Advanced compiler diagnostics can remain available, but the default experience should be understandable without knowledge of the compiler internals.

5. Build a Public Test Suite

The compiler needs tests that describe behavior rather than simply protect current implementation details.

We want tests covering at least:

• parsing;
• type handling;
• expressions;
• function calls;
• local variables;
• frame layout;
• memory operations;
• modules;
• imports and exports;
• artifact generation;
• expected compiler errors;
• generated instructions.

Some tests should operate at the language level.

Others should compare generated representations.

Eventually, parts of the test suite can be executed against Reganta and Memora8 to validate the complete path from source program to execution.

6. Document the Runtime ABI

One of the most important pieces of the public release will be the contract between generated code and the environment that executes it.

The compiler and runtime currently share assumptions about things such as:

• registers;
• frame layout;
• module layout;
• function identifiers;
• exported functions;
• parameters;
• memory;
• entry behavior.

Those assumptions need to become explicit.

The ABI should describe them without requiring someone to reverse-engineer the compiler.

A clear ABI also separates concerns.

The compiler can evolve independently.

Reganta can evolve independently.

Memora8 implementations can evolve independently.

As long as they preserve the relevant contracts, the system remains compatible.

7. Add Small, Inspectable Programs

A programming language is easier to understand through programs than through architecture diagrams alone.

The public repository should contain small examples showing one concept at a time.

For example:

hello
variables
functions
memory
modules
imports
exports
runtime module

The examples should remain deliberately small.

The objective is not to demonstrate how much code Sekura JS can run.

It is to make it easy to see how a source construct becomes a compiler artifact and eventually an executed operation.

8. Clean the Repository

Opening a repository is also an opportunity to remove accumulated development history that no longer represents the project.

That includes:

• obsolete experiments;
• temporary tools;
• generated files;
• machine-specific configuration;
• credentials and secrets;
• unused dependencies;
• abandoned formats;
• misleading documentation.

The first public version should be smaller than the internal development tree, not larger.

9. Choose the License and Contribution Model

The license defines more than whether source code can be read.

It affects how the compiler can be used, embedded, modified, distributed, and incorporated into other work.

We are also defining how external contributions should work.

At the beginning, we expect the project to remain architecture-led.

Not every feature that is useful in another language necessarily belongs in Sekura JS.

The purpose of opening development is not to turn the language into a collection of unrelated features.

It is to make its design inspectable and allow improvements that remain consistent with the architecture.

The Initial Open-Source Boundary

We do not intend to open every part of the Sekura stack at once.

The first useful boundary is much smaller.

The initial Sekura JS open-source release is expected to focus on:

Sekura JS language
Sekura JS compiler
language specification
compiler tests
examples
public build system
toolchain documentation

Reganta OS and Memora8 are separate projects with their own engineering paths.

Keeping these boundaries explicit should make it easier to understand what is stable, what is experimental, and what is currently being prepared for external use.

Open Source Is Not the Final Goal

Publishing the source code is an important milestone, but it is not the most interesting one.

The more important question is what becomes possible after the compiler is public.

Once the language semantics are documented, the compiler can be tested against them.

Once the compilation stages are explicit, individual transformations can be examined.

Once the runtime ABI is defined, the interaction between compiled programs and Reganta can be checked.

Once the processor architecture is sufficiently specified, generated code can be compared with Memora8 execution semantics.

This creates a much larger engineering question:

Sekura JS source
      ↓
   compiler
      ↓
 Reganta OS
      ↓
   Memora8
      ↓
observable execution

How much of this chain can be made mechanically verifiable?

We do not have a complete answer yet.

But making the compiler inspectable is a prerequisite for finding one.

Toward a Verifiable Computing Stack

The long-term direction of Sekura is becoming clearer.

Sekura JS defines programs.

The compiler transforms those programs.

Reganta provides the execution environment.

Memora8 defines the processor architecture underneath it.

Instead of treating these layers as independent black boxes, we want to define the contracts between them explicitly.

That gives us a path toward a computing stack in which increasingly important properties can be inspected, tested, and eventually proven.

Open sourcing Sekura JS is the first public step in that direction.

What Comes Next

Our current preparation sequence is approximately:

clean compiler dependencies
        ↓
stabilize public build
        ↓
define core language specification
        ↓
stabilize compiler CLI
        ↓
publish tests and examples
        ↓
document runtime ABI
        ↓
prepare public repository
        ↓
open source Sekura JS

We will publish more technical notes as this work progresses.

The next article will look inside the Sekura JS compilation pipeline and explain what happens between a .sjs source file and the generated .sasm, .sdef, .sobj, and .smod artifacts.