396 lines
8.4 KiB
Markdown
396 lines
8.4 KiB
Markdown
# 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.**
|