# Slovo Language Manifest: A Typed Structural Source Contract

Sanjin Gumbarevic<br>
hermeticum_lab@protonmail.com

> **The tree is the language.**

**Slovo** (<span class="glagolitic">ⰔⰎⰑⰂⰑ</span>) is a programming language designed for humans, tools, compilers, LLMs, and machines.

Its name means **word**.

Its Glagolitic spelling is <span class="glagolitic">ⰔⰎⰑⰂⰑ</span>.

Slovo is built on a simple belief:

> Source code should already be structure.

A Slovo program should be easy to read, easy to generate, easy to check, easy to transform, easy to repair, and easy to compile.

Slovo is not designed to be clever.

Slovo is designed to be clear.

---

## Purpose

Slovo exists for an age where programs are written, read, checked, transformed, and repaired by both humans and machines.

It is designed for:

- humans who want clarity
- tools that need structure
- compilers that need precision
- machines that need efficient code

LLMs are treated as tools that generate, repair, and explain code.

Slovo should allow a human, an artificial intelligence, a static analyzer, and a compiler to inspect the same program structure, and allow the machine to execute code derived from that structure.

The goal is not only to write programs.

The goal is to write meaning in a form that can become machine code.

---

## Core Idea

Most programming languages hide their structure behind syntax.

Slovo exposes structure directly.

In Slovo, source code is tree-shaped.

A form looks like this:

```slo
(name argument argument argument)
```

Example:

```slo
(+ 2 3)
```

A function is also a form:

```slo
(fn add ((a i32) (b i32)) -> i32
  (+ a b))
```

The source is close to the AST.

The AST is close to the compiler.

The compiler is close to the machine.

> **The tree is the language.**

---

## What Makes Slovo Different

Slovo is not primarily a Lisp, a scripting language, a macro system, or an academic intermediate representation.

Slovo is a typed structural language aimed at systems programming, where the written program, the checked program, and the lowered program remain visibly related.

Its central bet is that a language can make source code look like a tree without giving up native compilation, safety, tooling, or practical systems programming.

Slovo is built around continuity of structure:

```text
written tree
↓
parsed tree
↓
checked tree
↓
lowered tree
↓
LLVM IR
↓
machine code
```

The written form should not be a disguise.

The written form should be the beginning of the compiler's truth.

---

## The Four Readers

Slovo serves four readers:

- the human
- the tool
- the compiler
- the machine

LLMs are treated as tools that generate, repair, and explain code.

### The Human

A human should be able to read Slovo without guessing.

The language should avoid hidden behavior, ambiguous grammar, precedence traps, and unnecessary stylistic choices.

### The Tool

A tool should be able to parse, format, inspect, transform, repair, test, and explain Slovo code reliably.

Tooling is part of the language.

### The Compiler

A Slovo compiler should not need heroic parsing tricks.

The grammar should be small.

The core language should be smaller.

Every advanced feature should lower into a stable typed core.

### The Machine

Slovo should not be only symbolic.

It should compile efficiently.

The primary compilation target is **LLVM IR**.

---

## Canonical Form, Not Crudeness

Slovo values consistency over personal style.

There should not be five competing ways to increment a value.

Not this:

```text
x++
x += 1
inc x
x = x + 1
```

But this canonical core meaning:

```slo
(set x (+ x 1))
```

A Slovo formatter is part of the language.

Formatting is not decoration.

Formatting is shared understanding.

Surface conveniences may exist if they lower clearly into one canonical core form and the formatter makes their structure obvious.

The rule is not that Slovo must be minimal at all costs.

The rule is that Slovo must not let convenience hide meaning.

---

## Explicitness

Slovo does not guess silently.

A value of one type does not secretly become another type.

This should not be allowed:

```slo
(+ 1 2.5)
```

The conversion must be explicit:

```slo
(+ (cast f64 1) 2.5)
```

Explicitness makes programs easier for humans to review, easier for tools to repair, and easier for compilers to trust.

---

## Safety and Memory

In safe Slovo code:

- values are initialized before use
- nullable absence is represented by `option`
- recoverable failure is represented by `result`
- casts are explicit
- array and slice access is bounds-checked
- raw memory operations require `unsafe`
- unsafe code is lexically visible
- uninitialized memory is not observable from safe code

Safety does not mean the program is correct.

Safety means ordinary Slovo code avoids classes of machine-level undefined behavior unless the programmer explicitly enters `unsafe`.

Early Slovo should begin with a simple memory model:

```text
v0:
- managed heap values for safe code
- raw pointers only in unsafe
- slices are bounds-checked
- option/result instead of null/exceptions
- explicit allocation APIs
- no concurrency memory model yet
```

Later Slovo may evolve toward:

```text
v1+:
- arenas / regions
- ownership or affine resources if needed
- FFI memory contracts
- layout annotations
```

Memory must never be hidden magic.

Allocation, ownership, aliasing, and lifetime should become more visible as code moves closer to the machine.

---

## The Lowering Principle

Every surface feature must explain how it lowers.

If a feature cannot be described as a transformation into the typed core, it does not belong in the language yet.

A feature is not accepted because it is expressive.

A feature is accepted when its meaning remains visible after lowering.

Lowering is not an implementation detail.

Lowering is part of the language contract.

---

## LLVM as the Main Target

Slovo aims at LLVM.

The intended compiler pipeline is:

```text
Slovo source
↓
S-expression parser
↓
surface AST
↓
desugaring
↓
typed core AST
↓
Slovo IR
↓
LLVM IR
↓
native machine code
```

LLVM is not only a backend target.

It is a constraint that forces Slovo to define types, control flow, memory, and calling conventions precisely.

---

## Tooling Is Part of the Language

The parser, formatter, type checker, diagnostic format, package layout, test runner, and lowering inspector are part of Slovo's promise.

They are not optional accessories.

A Slovo implementation that accepts code the formatter cannot canonicalize is incomplete.

A Slovo implementation that reports errors only as unstructured text is incomplete.

A Slovo implementation that cannot show how a surface form lowers is incomplete.

The toolchain should make the tree visible.

---

## Non-Goals

Slovo is not trying to:

- replace Python for quick scripting
- be maximally terse
- support every programming paradigm
- become a macro playground in early versions
- hide machine costs
- optimize for clever one-liners
- compete with Lisp on dynamic metaprogramming
- compete with C on minimal implementation size
- compete with Rust on advanced borrow-checking before Slovo's core is stable

A language becomes stronger when it knows what it is not trying to be.

---

## Slovo and Lisp

Slovo honors Lisp.

It inherits the belief that simple symbolic forms can express deep systems.

But Slovo is not Lisp renamed.

Lisp traditionally treats code-as-data as a source of expressive power.

Slovo treats code-as-tree as a source of compile-time discipline.

Lisp asks:

> What can the programmer express?

Slovo asks:

> What can the human, tool, compiler, and machine all agree on?

Slovo takes Lisp's structural beauty and aims it at modern compilation.

---

## The Logo

The Glagolitic spelling of Slovo is:

<span class="glagolitic">ⰔⰎⰑⰂⰑ</span>

It is written letter by letter as *slovo*.

It should be drawn simply, with respect for its origin.

The symbol should be used with cultural humility, not as exotic ornament.

A good Slovo logo should feel like an old letter that learned to compile.

---

## Closing Declaration

Slovo begins with a simple belief:

A programming language can be symbolic without being vague.

It can be low-level without being hostile.

It can be AI-friendly without being gimmicky.

It can be old in spirit and new in purpose.

It can treat code as words, words as structure, and structure as something the machine can faithfully execute.

**Slovo is a language where source is structure.**

**The tree is the language.**
