sigmal-docs

Sigmal Language Specification — Part 06

Compilation Model, Runtime Assumptions, and Target Platforms

Top > Design docs > Core design > Part 06

1. Compilation Philosophy

Sigmal is a compiled language.

The core language is designed to:

Sigmal is not an interpreted, runtime-dependent language.

Compilation is ahead-of-time.

There is no required virtual machine or managed runtime.

2. Core-to-Backend Pipeline

Compilation proceeds conceptually in stages:

  1. Surface syntax parsing
  2. Elaboration to core calculus
  3. Const-normalization
  4. Type checking
  5. Structural lowering
  6. Target-specific code generation

Const-normalizable expressions are evaluated at compile time as part of semantics, not as an optimization.

All generated code must preserve:

Runtime execution may be non-terminating only via explicit effect encodings and their interpreters; the compiler must not introduce hidden divergence.

3. Runtime Assumptions

Sigmal makes minimal runtime assumptions.

There is:

Reference-counted types are permitted.

Manual or explicit allocator models are allowed.

Freestanding execution must be supported.

A default allocator may be provided by standard libraries for convenience, including on WASM targets.

4. Memory Model

The memory model must support:

There must be no hidden unbounded recursion at runtime.

Since the language is total, recursion must be structurally justified or encoded through data.

Explicit effect interpreters may execute indefinitely (e.g., event loops), but such nontermination must never arise from the pure fragment.

Precise ownership and borrowing semantics are not yet specified.

However:

5. Representation Strategy

Backends must define representations for:

Records should have:

Inductive types must support:

Symbol values may:

But their equality semantics must remain structural.

Symbol construction and representation are implementation-defined but must be deterministic for a fixed implementation and target.

6. Target Platforms

Primary targets include:

Hosted Targets

Freestanding Targets

Sigmal is designed to operate correctly in both hosted and freestanding contexts.

7. WASM Target Strategy

For wasm32-unknown-unknown:

A default allocator may be provided for convenience.

The generated module should:

8. ABI Considerations

Each backend target must define:

ABI design must:

Stable ABI specifications may be defined per target.

The .std.abi module provides the standardized ABI interface; its contents and behavior may vary by target, subject to the per-target ABI specification.

9. Linking and Resolution

Module resolution occurs before compilation.

The resolver provides a deterministic top-level module value.

The top-level module value includes standardized .std.* modules. In particular, .std.core is always available (including freestanding targets). Some .std.* modules (e.g. .std.abi) are target-dependent within their standardized interface.

Compilation must:

Cross-module linking must preserve structural type equivalence.

10. No Implicit World

Even in hosted environments:

Effects must be expressed explicitly via:

The runtime never injects a hidden context.

11. Determinism

Compilation must be deterministic:

Deterministic builds are a design goal.

Optimization passes must:

12. Optimization Constraints

Optimizations may include:

However, optimizations must not:

Const-normalization is semantic and cannot be skipped.

13. Open Questions (Compilation & Runtime)

14. Summary

Sigmal’s compilation model is:

There is:

All operational power arises from:

Sigmal aims to combine:

Sigmal.org - the calculus we can build on

This site is open source. Improve this page.