SL — Symbolic Language

SL is a statically typed, native-first general-purpose programming language built around a compact, composable ASCII symbol vocabulary.

The compiler currently targets LLVM and uses a small native ARC runtime. SL is being migrated from its bootstrap grammar to the frozen Syntax v1 language design.

:add:a_int,b_int[int]
    -> a + b

:main[int]
    result :< add:20,22
    print:result
    -> 0

Project status

SL is under active development.

The repository currently contains two closely related language states:

Bootstrap compiler syntax is the grammar implemented by the current compiler and used by example.syl, advanced.syl, and the existing runtime tests.

Syntax v1 is the frozen target language specification currently being implemented across the lexer, parser, semantic analyzer, SLIR, LLVM backend, and language tooling.

See LANGUAGE.md for the Syntax v1 specification.

Design goals

SL is designed around several principles:

• symbolic but systematic ASCII syntax;
• static typing with inference where practical;
• native-first compilation;
• LLVM as the primary production backend;
• an SL-owned intermediate representation rather than LLVM defining the language;
• deterministic ARC/value memory semantics;
• minimal, pay-for-use runtime support;
• typed recoverable errors rather than exception-heavy runtime unwinding;
• structured concurrency with explicit detached execution;
• C ABI interoperability;
• eventual self-hosting.

The major symbol families intentionally carry related meanings:

?     condition / selection
!     failure / negation
~     absence / deferred state
#     iteration
|     alternatives / streams / flow
:     declaration / application
::    resolution
@     current state / receiver
+     exposure / composition
^     inheritance / upward visibility
->    outward value flow

Syntax v1 preview

Control flow:

? condition
    ...

?? other_condition
    ...

??
    ...

Loops:

?* condition
    ...

*?
    ...
?* condition

Iteration:

#* item # items
    process:item

Typed errors:

:load:path_str[Config!IOError]
    file :< open:path!
    -> parse:file!

Structured concurrency:

task :< ~+ fetch:url
response :< ~> task

Detached/background execution:

log_event:event &

Postfix & is the Syntax v1 fire-and-forget/background form. Structured child tasks should use ~+.

Compiler architecture

The current production compiler still lowers directly from the parser/AST into LLVM.

The target architecture is:

SL source
   ↓
Lexer
   ↓
Parser
   ↓
AST
   ↓
Semantic analysis
   ↓
Typed AST
   ↓
SLIR
   ↓
Backend
   ↓
LLVM

The repository already contains the beginning of the reusable frontend and SLIR/backend layers.

LLVM remains the primary backend.

Installation

Requirements:

• Python 3.10+
• LLVM/llvmlite dependencies
• C compiler
• Make

Clone the repository:

git clone https://github.com/robruon/sl
cd sl

Install:

chmod +x install.sh
./install.sh

The installer creates the local compiler environment, builds the SL native runtime, and installs:

~/.local/bin/sl

Verify:

sl example.syl --run

Commands

Compile to LLVM IR:

sl example.syl

Run through the LLVM JIT:

sl example.syl --run

Compile an object file:

sl example.syl -o example.o

Create an SL bundle:

sl bundle file.syl

This produces:

file.sylb

Run the language server:

sl lsp

sl lsp speaks the Language Server Protocol over standard input/output. It is intended to be shared by VS Code, JetBrains IDEs, Neovim, and other LSP clients.

Bundles

.slb is the SL bundle format.

A bundle is created with:

sl bundle file.syl

Bundles are package/distribution artifacts and are distinct from ordinary .syl source files.

Editor tooling

The VS Code extension provides:

• .syl language recognition;
• Syntax highlighting;
• SL snippets;
• file and bundle icons;
• connection to the external sl lsp language server.

The language server is editor-independent.

Long-term editor architecture:

                 sl-lsp
                   │
        ┌──────────┼──────────┐
        │          │          │
     VS Code    JetBrains   Neovim

Language intelligence should live in the compiler frontend/LSP rather than being reimplemented independently by each editor.

Examples

The root examples currently target the runnable bootstrap compiler:

example.syl
advanced.syl
modules.syl

Syntax v1 examples should live under:

examples/syntax-v1/

until the Syntax v1 parser becomes the default compiler frontend.

Runtime

SL currently uses a small native ARC runtime for features including:

• reference-counted objects;
• strings;
• dynamic arrays;
• weak references;
• generator/runtime helpers.

The runtime is built as:

libarc.dylib    macOS
libarc.so       Linux

The long-term generator and async implementation is intended to lower suspension points into compiler-generated state machines instead of depending permanently on platform-specific ucontext behavior.

Repository structure

arc/                    native ARC/runtime implementation
compiler/               reusable compiler/frontend/SLIR infrastructure
sl_lsp/                 editor-independent language server
sl-vscode/              VS Code integration
stdlib/                  SL standard-library modules
tests/                   compiler/tooling tests

lexer.py                 bootstrap lexer
parser.py                bootstrap parser/AST
codegen.py               current LLVM compiler/JIT
LANGUAGE.md              Syntax v1 specification

Roadmap

Current development direction:

editor/LSP stabilization
        ↓
workspace + cross-file language intelligence
        ↓
Syntax v1 lexer/parser migration
        ↓
semantic analysis / type system
        ↓
Typed AST
        ↓
SLIR lowering
        ↓
LLVM backend migration
        ↓
self-hosting work

Registry

The SL package registry is developed separately at:

https://github.com/robruon/sl-registry

The registry is intentionally early enough that package compatibility, syntax-version metadata, dependency locking, and integrity metadata can be established before a large package ecosystem forms.

License

See LICENSE.