Cyr est le dialecte natif de Cyra — compilé en AOT via LLVM, des serveurs jusqu'au plus dépouillé des MCU. Sans VM, sans GC. Le langage que les machines écrivent, désormais sur le métal.
Cette page partage les premières idées, la philosophie de genèse et les attentes pour Cyr. Le nom, la relation tronc/branche, les noms du runtime et de la CLI, ainsi qu'un ensemble de décisions clés sont figés — mais Cyr n'est pas encore livré. Ce que vous lisez ici est une charte, pas une version publiée.
Pourquoi Cyr existe
Cyra excelle là où la BEAM excelle : les systèmes concurrents, tolérants aux pannes et rechargeables à chaud. Mais des classes entières de travail vivent sous cette ligne. Aujourd'hui, un développeur qui heurte le mur doit descendre vers C, Rust ou Zig et quitter entièrement le langage. Cyr est l'issue de secours qui vous maintient dans la famille.
Cyr compile en avance (AOT) vers du code objet natif via LLVM — pas de VM, pas de JIT. Un binaire autonome qui s'exécute sur une plateforme Tier-1 sans rien d'installé.
cyrtUn petit runtime lié à chaque binaire — allocateur, gestionnaire de panique, intrinsèques. Visé à quelques centaines de kilo-octets, pas des méga-octets. Embarqué et plausible en WASM.
@external(c, "...") est l'unique surface d'interopérabilité native.
Appelez du C et soyez appelé par du C avec des signatures complètes, des
largeurs explicites et une nullabilité explicite — sans glu écrite à la main.
Flux uniquement par switch, Option/Result,
types explicites — une grammaire identique à ~85 % à celle de Cyra. La
compétence et le code source franchissent la frontière géré/natif.
Un langage, deux dialectes
Une grammaire, un noyau sémantique, deux backends — à la manière dont C a une implémentation hébergée et une autonome. Le tronc est la grammaire partagée ; les deux branches ne divergent que là où le modèle de runtime les y contraint.
// le dialecte BEAM
Chaleureux et géré. S'exécute sur une machine.
pid / ref / port:erlang.* · stdlib Cyra.*// le dialecte natif
Bare metal. Est le code machine.
ptr<T>, @external(c, "...")bigint sur optioncyrt · stdlib Cyr.*Portée système & OS
Cyr vise explicitement le développement système et OS de bas niveau — jusqu'à
et y compris un init/PID 1, des démons, des pilotes et du code
autonome bare-metal. Plus le profil est exigeant, plus le langage s'efface. La
portée de Cyr s'organise en trois profils d'exécution.
application · démon · CLI
Un programme natif ordinaire sur un OS complet. Toute la pile est disponible, et
cyrt utilise le tas et les threads de l'OS.
init / PID 1 · binaire statique minimal
Un noyau est présent mais l'espace utilisateur est minimal. PID 1 ne devrait pas traîner une libc complète — une fine couche d'appels système directs dialogue avec le noyau.
noyau · bootloader · firmware · ISR
Aucun OS du tout. Vous apportez l'allocateur ; il n'y a ni threads, ni libc,
ni déroulement de pile. Asm inline, volatile/MMIO, atomiques,
points d'entrée personnalisés.
En action
Un fragment de pilote avec FFI C23, agencement compact, Option au lieu de
null, et récursion terminale qui s'exécute en pile constante — le tout dans la
syntaxe Cyra familière.
module Sensor.Driver {
use Cyr.Result;
// C23 FFI — the single native interop surface
@external(c, "read_register")
fn read_register(addr: ptr<u32>) -> u32;
@repr(packed)
struct Reading { id: u16; value: i32; }
// switch-only flow; Option<T> for absence, never null
pub fn decode(raw: u32) -> Option<Reading> {
switch raw {
0 => None;
_ => Some(Reading { id: 1, value: raw as i32 });
}
}
// guaranteed constant stack — TCO holds at the CIR layer
fn sum(xs: list<i64>, acc: i64) -> i64 {
switch xs {
[] => acc;
h :: rest => sum(rest, acc + h); // i64 traps on overflow
}
}
@entry
pub fn main() -> i32 { 0; }
}Ce qui est déjà figé
Cyr part des prémisses que Cyra a déjà établies, plus un ensemble de portes à sens unique ratifiées par le conseil philosophique à la genèse. Ce sont les attentes auxquelles Cyr s'engage.
i64 par défaut ; l'arithmétique déclenche un trap
par défaut. wrapping, saturating et bigint
sont des options explicites.
nil est retiré des types non-Option. Le null ne vit
que derrière ptr/any, au mur du C.
La récursion en position terminale — y compris la récursion mutuelle — s'exécute en pile constante. Une garantie sémantique au niveau CIR, pas une foi en LLVM.
La mémoire est ARC + arène sur option + weak. La sûreté est
relocalisée dans les valeurs par défaut du compilateur, pas dans des annotations
de durée de vie écrites par l'auteur — le bon choix pour un corpus rédigé
par un LLM.
unsafe bruyant et minimal
Le déréférencement brut de ptr<T> et les down-casts
any ne vivent qu'à l'intérieur d'unsafe —
repérables au grep et auditables.
Cyr.* distincte
Cyr réécrit sa bibliothèque standard nativement. La portabilité vit dans la
grammaire, pas dans les noms de bibliothèque — une ligne use
est toujours honnête sur son dialecte.
Positionnement honnête
Cyr n'est pas « Cyra 2.0 » et ne diverge pas en syntaxe. C'est un seul langage avec deux backends — pas deux langages en concurrence.
Cyr fait partie du même projet — mêmes outils, même communauté — et non d'un produit rival doté de sa propre identité.
pid, ref, port, spawn,
receive, send sont supprimés. Tout ce qui ressemble à
un acteur est une bibliothèque, pas une primitive du langage.
Cyr s'adresse aux gens qui aiment déjà Cyra et veulent maintenant écrire la couche située sous leurs applications — pas un argumentaire destiné au grand public de la programmation système.
Philosophie de conception
« Continuité du code source et de la compétence »
La maxime pragmatique de Peirce est le test de Cyr : quelle différence concrète Cyr fait-il que « Cyra plus utilisez simplement C » ne fait pas ? La réponse — la continuité du code source et de la compétence à travers la frontière géré/natif — gouverne chaque choix de conception.
« Grammaire partagée, bibliothèque honnête »
Les dialectes partagent ~85 % de leur syntaxe — le véritable actif transférable. Ils ne partagent délibérément pas les noms de bibliothèque : la cohérence appartient à la syntaxe et à la CLI ; l'honnêteté appartient à l'espace de noms.
« Vingt et un philosophes, une charte »
Les Quatre Causes d'Aristote cadrent l'effort ; Popper nomme ce qui falsifierait le succès ; les antinomies de Kant maintiennent le conseil honnête. Dix-huit domaines de conception ouverts ont été lus par les vingt et un, et les décisions clés ratifiées — le conseil fonctionne sous le nom d'organon, ouvert sur GitLab.