Flux — documentation du langage et du FDK

Flux est un langage applicatif total, causal et déterministe pour la plateforme web. Un programme Flux n'est pas une séquence d'instructions — c'est un graphe de dataflow typé : chaque valeur est un flux, chaque flux porte un kind (sa dimension, pas seulement sa forme), et le moteur — et non l'auteur — prend en charge l'évaluation, l'incrémentalité, la mémoire et l'ordonnancement. Quatre plans coopérants séparent ce qu'un programme calcule (ANALYSIS) de ce qu'il montre (CANVAS), de la façon dont il s'anime d'un état à l'autre (TRANSITION), et de la façon dont il interagit et persiste (APP) — avec un pare-feu à sens unique entre eux qui rend les garanties fondamentales structurelles plutôt que disciplinaires.

Le langage est livré avec le FDK (Flux Development Kit) : le prélude standard et les API des piliers — compute (dataframes, statistiques, maths métier), collections, color, text, i18n, units, réseau, display, host services, le plan server, et l'identité asset/currency — tous bornés, sous contrôle de capacités, et spécifiés au même niveau de déterminisme que le cœur.

Une seule VM de dataflow se tient derrière de nombreux types d'application — un graphique en direct, une interface interactive, une scène animée, un jeu vérifié côté serveur — parce que les quatre plans couvrent calculer → montrer → animer → interagir. Flux est généraliste ; ses spécialisations métier se posent par-dessus, et le fer de lance en est le tracé de graphiques financiers et l'analyse de marché, ce qui explique pourquoi beaucoup d'exemples tracent des prix — bien que rien dans le modèle ne soit spécifique aux marchés. Une seule ligne suffit pour saisir le caractère du langage :

fluxplot rsi(close, input(14))   // osc(0,100) → its own pane, 0–100 scale, 30/70 guides, params UI — all inferred

#Parcours de lecture

• Nouveau sur Flux — lisez le livre dans l'ordre : Qu'est-ce que Flux → Piliers de conception → Premiers pas → Les quatre plans.
• Écrire des programmes — le livre de recettes, puis la référence du FDK pour l'API dont vous avez besoin, avec la référence du langage à portée de main.
• Évaluer les garanties — Garanties, puis Compilateur et runtime et Kinds.
• Étendre l'hôte (représentations, outils, panneaux) — Intégration hôte.

#La carte

#Le livre

#Référence du langage

#Référence du FDK

#Rouages internes

#Guides

#État d'implémentation

La documentation décrit Flux v1 tel que spécifié par les plans de conception scellés (docs/DESIGN-flux-*.md). L'état en un coup d'œil :

Les pages individuelles ne répètent pas ce tableau ; les fonctionnalités que la conception elle-même diffère sont étiquetées Post-v1, Réservé, ou Décision ouverte en ligne (voir les conventions ci-dessous).

#Conventions utilisées partout

• Les kinds sont écrits en style code : price, level, osc(0,100), signal, vec(κ, N), record{…}.
• Les codes d'erreur sont verbatim et porteurs de sens : [ErrDim], [ErrCausal], [ErrTotal], [ErrFirewall], [WarnTop]…
• Les invariants sont numérotés I1–I7 (le contrat horloge/déterminisme) ; les règles d'amendement A1–A15 affinent le système de kinds.
• Les lignes d'exemple portent des annotations pédagogiques : plot x // level → centered pane ; les formes rejetées sont marquées // ✗ [ErrDim] ….
• Post-v1. / Réservé. / Décision ouverte. étiquettent en ligne le matériel dont la conception est différée.

#Voir aussi

• Qu'est-ce que Flux — commencez ici si le langage est nouveau pour vous.
• Premiers pas — le premier programme, et ce qu'il infère pour vous.
• Kinds — le système de types dimensionnel sur lequel tout le reste s'appuie.
• Garanties — ce qui est promis, et comment chaque promesse est vérifiée par machine.
• Vue d'ensemble du FDK — les bibliothèques et le modèle de capacités.
• Glossaire — chaque terme, défini précisément.

Qu'est-ce que Flux

Flux est un langage applicatif total, causal et déterministe pour la plateforme web. C'est un langage généraliste doté de spécialisations métier — le tracé de graphiques financiers et l'analyse de marché sont la spécialisation phare, pas la définition. Vous pouvez écrire un indicateur en une ligne, une scène animée en cinq, ou une application interactive complète en cinquante ; tous sont le même genre d'objet : un graphe de dataflow pur sur des flux typés, exécuté par un hôte qui garantit — par construction, et vérifié par machine — que le programme se termine, ne réécrit jamais son propre passé, produit les mêmes octets sur chaque machine, et ne peut toucher à rien qui ne lui ait été explicitement accordé.

Ce chapitre vous donne la forme du langage tout entier : l'idée unique qui le sous-tend, les quatre plans dont un programme est fait, à quoi ressemblent les programmes, où ils s'exécutent, à qui ils s'adressent, et ce que Flux ne fait délibérément pas. Tout est détaillé dans les chapitres ultérieurs ; rien ici ne requiert de connaissance préalable de Flux ni du trading.

#Une idée : chaque valeur est un flux

Une valeur Flux n'est pas un nombre posé dans une variable. C'est un flux : une valeur telle qu'elle évolue le long d'un axe ordonné d'unités de données — relevés de capteurs, entrées de journal, tours de jeu, ou (dans le domaine phare) barres de marché. close n'est pas « le dernier prix » ; c'est l'historique complet des prix de clôture, une valeur par unité, jusqu'à maintenant.

Tout découle du fait de prendre cela au sérieux :

• Une constante est un flux dégénéré — la même valeur à chaque unité. 2 et close sont la même sorte de chose, donc ils se combinent librement.
• L'arithmétique est élément par élément. fast - slow soustrait deux historiques entiers, unité par unité — pourtant le moteur l'évalue de façon incrémentale, une nouvelle valeur par nouvelle unité.
• Il n'y a ni index ni boucle. Vous n'écrivez jamais for i, ne gérez jamais de tampon, ne décidez jamais quand recalculer. Vous décrivez ce qu'une valeur est, pas quand la mettre à jour.

fluxfast = ema(close, 12)          // a stream: the 12-unit exponential average, over all history
slow = ema(close, 26)
plot fast - slow               // element-wise difference — itself a stream

Parce que les flux sont des valeurs, la composition fonctionnelle ordinaire constitue tout le modèle de programmation : des fonctions de flux vers flux (def), des enregistrements de flux (bb.upper), des flux d'enregistrements, des flux pilotant des propriétés visuelles. Il y a une seule algèbre, appliquée partout.

#Décrivez une expression ; le moteur évalue

Le modèle mental en une phrase : vous décrivez une expression pure, le moteur l'évalue. Vous n'écrivez jamais la boucle, le tampon, ou le await. Le compilateur inline vos définitions dans un DAG incrémental typé (graphe orienté acyclique) d'opérations, le vérifie — kinds, causalité, totalité, frontières de plans — choisit un noyau natif pour chaque nœud qu'il reconnaît, planifie sa mémoire statiquement, puis l'exécute soit par unité (en direct, un pas par nouvelle unité de données), soit en lot (rejeu sur tout l'historique). Les deux exécutions sont la même fonction et produisent les mêmes octets.

C'est pourquoi un programme Flux n'a pas de code de cycle de vie. Il n'y a pas de callback « à chaque nouvelle barre », pas de gestion de souscriptions dans le code ANALYSIS, pas d'invalidation de cache : le DAG est le graphe de dépendances, et le moteur le fait avancer. C'est aussi pourquoi le moteur peut faire des promesses fortes — un graphe pur, typé, borné et acyclique est un objet que vous pouvez vérifier, ordonnancer, paralléliser et optimiser sans changer son sens.

#Quatre plans, un seul pare-feu à sens unique

Une application complète a des parties aux besoins très différents. Un calcul doit être exact et reproductible. Une animation doit lire l'horloge et peut recourir à l'aléatoire. Une transition d'écran doit pouvoir interpoler librement sans corrompre les données. L'état applicatif doit répondre aux événements utilisateur et déclencher des effets. Flux ne moyenne pas ces besoins en un seul compromis ; il les sépare en quatre plans coopérants — un langage, une algèbre d'expressions, quatre jeux de règles :

Les plans sont reliés par un pare-feu à sens unique : la présentation peut lire l'analyse ; l'analyse ne lit jamais la présentation. Une scène CANVAS peut briller plus fort quand une valeur ANALYSIS monte ; une expression ANALYSIS qui tente de lire la souris, l'horloge murale ou un signal aléatoire sans graine est rejetée à la compilation avec [ErrFirewall]. Le plan APP lit les séries via des souscriptions typées et ne peut jamais écrire dans ANALYSIS.

Pourquoi cette règle existe. Le pare-feu est ce qui permet aux garanties et à la liberté de coexister dans un même programme. Votre signal reste no-repaint de façon prouvée — une valeur, une fois produite pour un pas, ne change jamais — même tandis qu'un effet animé et aléatoire danse juste à côté, parce que le langage rend impossible que l'effet reboucle dans le signal. Toute valeur qui compte vit du côté discipliné du mur ; tout ce qui est décoratif vit du côté libre.

Le chapitre Les quatre plans couvre chaque plan en profondeur.

#À quoi ressemble un programme — trois avant-goûts

#Un analytique, en une ligne

fluxplot rsi(close, input(14))     // rsi : osc(0,100) → own pane, 0–100 scale, guides 30/70

Cette seule ligne est un programme complet et livrable. Tout le reste est inféré du kind de l'expression — le type dimensionnel qui dit ce que la valeur est physiquement, pas seulement sa largeur :

• close a le kind price ; rsi mappe toute quantité scalaire vers osc(0,100) — un oscillateur borné et sans dimension.
• Un osc(0,100) ne partage aucune échelle avec le prix, donc il se matérialise dans son propre panneau plutôt que sur le graphique des prix — avec une échelle 0–100 fixe.
• Les lignes de repère conventionnelles à 30 et 70 proviennent des métadonnées de l'opération et sont tracées automatiquement.
• input(14) déclare un paramètre : l'éditeur en dérive un contrôle, la valeur réglée vit avec l'instance du graphique (la source conserve la valeur par défaut), et l'ajuster réexécute le graphe sans recompiler.
• La série est enregistrée — nom, style de rendu, classe sémantique, jusqu'à sa description d'accessibilité — tout dérivé du kind.

Rien concernant le placement, l'échelle, les lignes de référence ou la tuyauterie des paramètres n'est écrit où que ce soit, et rien de tout cela n'a besoin de l'être. Quand vous voulez vraiment le contrôle, chacun de ces défauts est surchargeable sur place — voir Premiers pas.

#Une scène qui bouge

fluxcircle { at:(spring(close)); glow: 16; trail: 24 }         // a comet easing toward the price
on every(1 bars) -> spawn ring { r: 6->24; life: 200 bars }

Ceci est le plan CANVAS. Son axiome : chaque propriété est un signal. Une constante, un flux de données et un générateur d'animation comme spring(close) — un signal qui tend continûment vers sa cible — sont la même sorte de chose et se combinent avec la même algèbre. Il n'y a pas d'API d'animation séparée à apprendre : vous câblez des signaux dans des propriétés, et les événements (on … ->) engendrent ou interpolent des primitives. La scène se compile une fois en une structure retenue ; l'hôte route chaque signal vers le chemin d'exécution le moins coûteux (en cache, par unité, ou piloté par le compositeur).

#Une application

fluxvariant Msg { Inc | Reset }
app counter {
  init(p) = { n: 0 }
  update(m, msg) = match msg {
    Inc   -> { model: m with { n: m.n + 1 }, cmds: [] }
    Reset -> { model: m with { n: 0 }, cmds: [] }
  }
  view(m) = panel(slot: right.panel) { text("count {m.n}") ; button("+1", Inc) }
  subs(m) = []
}

Ceci est le plan APP : The Elm Architecture (TEA), durcie. Un Model (état borné et typé), une fonction update pure et totale qui replie les messages en un nouvel état plus une liste de commandes — descriptions d'effets inertes que l'hôte peut exécuter — une view pure qui renvoie un arbre de primitives d'UI validées, et des souscriptions déclaratives (subs) par lesquelles le monde ambiant (temps, données, gestes de l'utilisateur) entre sous forme de messages. Parce que update est un repli pur sur un journal de messages, l'état applicatif est rejouable par construction : le journal est l'unique source de vérité. Cette app ne demande aucune capacité, donc l'hôte ne lui laissera rien faire au-delà de dessiner sa vue et recevoir ses propres messages.

#Une flèche, cinq lectures

Vous avez maintenant vu la flèche -> trois fois, signifiant trois choses différentes — l'action d'un événement, une branche d'un match, et (au chapitre suivant) une lambda. C'est délibéré, et c'est le seul élément de syntaxe qui vaille la peine d'être appris d'emblée, parce que Flux a exactement un seul token de flèche et il porte cinq lectures, chacune sélectionnée par son contexte :

L'analyseur n'a jamais à deviner : une tête de mot-clé revendique la flèche, et partout ailleurs le kind de la position décide. La récompense, c'est que vous ne trimballez jamais une table de symboles fléchés dans votre tête — il n'y en a qu'un, et vous le lisez depuis son contexte.

#Où s'exécutent les programmes

Un programme Flux a deux véhicules d'exécution et un seul sens. Pendant que vous éditez, un interpréteur évalue le DAG directement — retour instantané, valeurs par nœud que le débogueur peut lire, aperçu en direct à chaque frappe. Quand un programme s'exécute pour de vrai — ou est livré à quelqu'un d'autre — il est compilé en un module WebAssembly et exécuté dans un bac à sable. Les deux ne sont pas « proches » : ils sont bit-identiques. L'invariant I7 exige que l'interpréteur et le module compilé produisent exactement les mêmes octets sur les mêmes entrées, et la chaîne d'outils le vérifie à chaque compilation en exécutant les deux et en affirmant l'égalité — une divergence empêche l'artefact d'être livré. La même discipline s'étend à travers les machines : l'évaluation en virgule flottante est scalaire et non réassociée, et chaque routine ayant une marge de variance selon la plateforme (maths transcendantes, arithmétique décimale, Unicode, calendriers, génération aléatoire, la représentation des valeurs manquantes) est épinglée à une seule implémentation partagée. Ce que vous avez vu dans l'éditeur est ce qui s'exécute, partout, jusqu'au dernier bit. La machinerie est spécifiée dans Compilateur et runtime.

#Le langage d'une plateforme : deux niveaux de confiance

Flux n'est pas une niche d'extension embarquée ; c'est le langage dans lequel la plateforme elle-même est écrite, et le langage dans lequel ses utilisateurs l'étendent. Les deux publics partagent un seul langage et un seul bac à sable, distingués uniquement par la confiance — les capacités accordées, jamais le code :

• Niveau A — first-party. L'interface de la plateforme elle-même, y compris ses outils les plus exigeants, est écrite en Flux. Sa source reste privée et est livrée en WASM compilé — la plus forte affirmation possible que le langage est suffisant pour de vraies applications.
• Niveau B — auteurs et utilisateurs. N'importe qui peut écrire des indicateurs, des représentations, des outils de dessin et des applications. Un artefact partagé ou acheté arrive en WASM uniquement, jamais en source : le travail de l'auteur est protégé, et le consommateur exécute un binaire non fiable en toute sécurité — parce que les scripts sont totaux (ils ne peuvent pas s'emballer), en bac à sable (le langage n'a aucune primitive d'E/S à détourner), et à refus par défaut : chaque effet requiert une capacité, et un artefact porte un manifeste inspectable, agrégé transitivement, de tout ce qu'il peut demander, visible avant l'installation.

Post-v1. Le déploiement du partage public et de la place de marché est différé ; le modèle de confiance qui le rend sûr est en v1 et n'est affaibli nulle part.

#Ce que Flux ne fait délibérément pas (v1)

Les limites assumées font partie de la conception. Chacune est un choix avec une justification, pas une lacune :

• Pas de boucles à exécution libre. Flux est total, pas Turing-complet — par choix. Les fenêtres, les replis et les boucles existent, mais chaque borne est une constante à la compilation sous un plafond. Un programme qui ne peut pas énoncer sa borne est rejeté avec [ErrTotal] à la compilation plutôt que tué par un timeout à l'exécution. (Décision ouverte. Une échappatoire unsafe opt-in pour une boucle non bornée est discutée dans la conception et déconseillée par défaut ; rien dans le catalogue n'en a besoin.) Voir Piliers de conception.
• Pas d'E/S directes depuis les scripts. Le langage n'a pas de fetch, pas de DOM, pas d'eval, pas de descripteurs de fichiers. Les effets sont arbitrés par l'hôte : un script émet des données de commande inertes sous des capacités déclarées, et l'hôte les exécute. C'est ce qui fait de l'exécution de code non fiable un acte de routine plutôt qu'une évaluation des risques.
• Grain temporel centré sur la barre. L'horloge ANALYSIS avance sur les unités de données clôturées. La granularité au niveau du tick et du flux d'ordres est une extension post-v1 nommée, pas une promesse implicite.
• Les données externes hors-prix restent en dehors d'ANALYSIS. Les données alimentées par le réseau entrent dans le plan APP via des souscriptions typées ; elles ne peuvent pas devenir silencieusement un « indicateur ». Réservé. Le kind metric nomme la jonction par laquelle un flux de données externe causal pourrait entrer plus tard dans ANALYSIS, délibérément maintenue ouverte et inerte en v1.
• Pas de scan de tout le marché, pas de gestion de portefeuille. Le travail inter-séries sur une poignée d'instruments nommés est de première classe ; scanner le marché entier, et gérer de nombreuses positions simultanées, ne sont pas des préoccupations de v1. (Un screener borné — une fonction totale mappée sur un univers à capacité fixe, avec un top-K à clé — est un pilier Post-v1. scellé ; c'est un map-reduce borné, jamais un scan non borné.)
• Pas de migration de code automatique. Flux ne livre pas de convertisseur depuis d'autres écosystèmes de scripts. Sa sémantique exclut délibérément des motifs que certains écosystèmes permettent (éditions rétroactives de l'historique, boucles non bornées, E/S ambiantes), de sorte qu'une traduction automatique fidèle est impossible pour toute une classe de programmes ; la documentation enseigne plutôt directement les motifs Flux équivalents.
• Post-v1. Les harnais de backtest de stratégies, la livraison d'alertes à distance, et la synchronisation multi-appareils sont conçus mais différés ; les alertes locales (alert) sont en v1.

#Comment lire cette documentation

Le livre (cette section) construit le modèle mental dans l'ordre :

1. Qu'est-ce que Flux — ce chapitre.
2. Piliers de conception — les sept garanties, pourquoi chacune existe, et ce que chacune vous apporte.
3. Premiers pas — une première session guidée, d'une ligne à une petite application.
4. Les quatre plans — ANALYSIS, CANVAS, TRANSITION et APP en profondeur, y compris le pare-feu et les valeurs en direct.

Autour du livre :

• Référence — le langage normatif : structure lexicale, grammaire, kinds, opérateurs, inférence, temps et état, canvas, transitions, le plan APP.
• FDK — le Flux Development Kit : le prélude de la stdlib et les API des piliers (compute, collections, color, text, i18n, units, net, display, host services, server, asset/currency) plus le catalogue de capacités.
• Rouages internes — comment les garanties sont implémentées : compilateur et runtime, modèle mémoire, optimiseur, concurrence, packages, intégration hôte.
• Guides — le livre de recettes, la page des garanties, l'éditeur, la FAQ et le glossaire.

Si vous ne lisez qu'une page de plus, lisez Piliers de conception : chaque décision de conception du langage remonte à l'un des sept.

#Voir aussi

• Piliers de conception — les sept garanties derrière tout ce qui précède.
• Premiers pas — écrivez votre premier programme dans les dix prochaines minutes.
• Les quatre plans — le modèle de plans et le pare-feu, en profondeur.
• Garanties — ce qui est promis et comment chaque promesse est vérifiée par machine.
• Index du FDK — la surface d'API destinée aux auteurs et le modèle de capacités.
• README — la carte de la documentation et l'état d'implémentation.

Piliers de conception

Chaque décision de conception dans Flux remonte à sept piliers. Chaque pilier est une propriété que le langage impose par construction — pas une convention, pas une règle de linter, pas une bonne pratique, mais quelque chose que le compilateur prouve sur chaque programme accepté et, là où la preuve a besoin d'aide, vérifie par machine à chaque compilation. Ce chapitre énonce chaque pilier, explique pourquoi il existe, détaille ce qu'il vous apporte concrètement, et le montre dans un micro-exemple.

Lisez ce chapitre pour comprendre pourquoi Flux a la forme qu'il a ; lisez Premiers pas pour le ressentir en pratique.

#1. Total, pas Turing-complet

L'énoncé. Chaque programme Flux se termine, et son coût par pas est connu à la compilation. Il n'y a pas de boucles non bornées, pas de récursion non bornée, pas de collections non bornées.

Pourquoi. Flux appartient à la famille du dataflow synchrone (dans la lignée de Lustre et SCADE) : des langages bâtis pour des systèmes où « le programme pourrait ne pas finir ce pas » n'est pas une issue acceptable. Un hôte de graphique doit faire avancer chaque script actif à chaque unité de données dans un budget de frame ; une plateforme qui exécute le code d'autrui doit borner ce que ce code peut consommer. La Turing-complétude retirerait exactement ces garanties — le problème de l'arrêt rend un script non borné impossible à budgéter — et n'apporte rien dont de vrais programmes analytiques aient besoin. La totalité est un choix, et Flux le fait ouvertement.

Ce que cela vous apporte.

• Terminaison garantie. Aucun script ne se bloque, jamais — ni le vôtre ni celui d'autrui.
• Un budget statique. La mémoire et le coût par unité sont calculés à la compilation ; un programme qui dépasse le budget est rejeté avant de s'exécuter avec [ErrTotal], avec la borne fautive nommée — jamais tué en cours d'exécution par un timeout.
• Bac à sable par construction. Un programme total sans primitives d'E/S ne peut pas être transformé en arme pour une attaque par épuisement de ressources. C'est la fondation sur laquelle reposent les niveaux de confiance.
• Vérifiabilité partout ailleurs. Les vérifications statiques (kinds, causalité, exhaustivité) sont décidables parce que le langage est total et que ses bornes sont des constantes.

En pratique. L'itération existe — bornée, et franche à ce sujet :

fluxhi20 = highest(close, 20)                        // windowed reducer — the bound is a constant
w    = window(close, 20)                         // the same 20 values as a vec, for map/fold
hi   = scan(close, (prev) -> math.max(prev, close))   // running state with feedback (see pillar 2)

window avec map/fold couvre les boucles comptées, scan couvre l'état courant, et loop(max, …) couvre « itérer jusqu'à terminaison » avec un plafond déclaré. Chaque borne est une constante à la compilation sous un plafond global ; une longueur dépendante des données est une erreur de kind, pas une surprise à l'exécution.

#2. Causal par construction

L'énoncé. Une valeur produite pour un pas ne peut plus jamais changer ensuite. L'historique est immuable — non comme une discipline que l'auteur maintient, mais comme un théorème du langage.

Pourquoi. Dans tout système qui réévalue sur un historique croissant, le défaut le plus mortel est la valeur qui change rétroactivement en douce : un analytique qui semblait prophétique sur l'historique parce que, à chaque pas passé, il avait silencieusement lu des données qui n'existaient pas encore. Le résultat est une divergence direct/rejeu qu'aucun test n'attrape, parce que les deux exécutions sont « correctes » — pour des définitions différentes du temps. Flux élimine le défaut à la racine en le rendant inexprimable : aucune construction du langage ne peut lire le futur.

Trois règles produisent le théorème :

• Les délais ne regardent que le passé. x[n] atteint n pas en arrière, avec n ≥ 0 une constante. Un délai négatif ne s'analyse en aucun sens ; il lève [ErrCausal].
• Le rééchantillonnage ne lit que les unités clôturées. x @ "1d" lit la dernière unité journalière clôturée — jamais celle encore en formation, et jamais une clôture future. (L'unité en formation est accessible pour l'affichage seulement, via live(), que le pare-feu tient à l'écart de toute analyse.)
• La rétroaction doit passer par un délai unitaire. Tout cycle dans le graphe doit traverser x[1] (la règle que scan respecte en interne), de sorte que la sortie d'aujourd'hui peut dépendre de la sortie d'hier mais jamais d'elle-même.

Par induction sur le graphe : output[t] = f(inputs[0..t]), mathématiquement. Une valeur passée n'a plus rien dont dépendre, donc rien ne peut la déplacer. Cette propriété s'appelle no-repaint — une valeur, une fois produite pour un pas, ne change jamais — et elle tient pour chaque programme accepté, pas pour un sous-ensemble soigné.

Ce que cela vous apporte.

• Direct ≡ historique. Le flux que vous calculez en direct et le flux que vous rejouez sur l'historique sont la même fonction — l'épine dorsale honnête de toute évaluation.
• Des signaux dignes de confiance. Un croisement qui s'est déclenché reste déclenché. Les marques et les alertes reposent sur un sol qui ne peut pas bouger.
• Vérifiable par machine. La causalité est une propriété de graphe (pas de cycles à délai nul), décidée à la compilation — la même idée de calcul d'horloges prouvée dans les langages synchrones.

En pratique.

fluxprev  = close[1]                 // yesterday's close — legal, and na on the first bar
gain  = math.max(close - prev, 0)
peek  = close[-1]                // ✗ [ErrCausal] — a negative delay reads the future

Le rejet vient avec sa raison : une valeur venue du futur forcerait vos valeurs passées à changer une fois que la réalité rattrape son retard.

#3. Déterministe à l'octet près

L'énoncé. Le même programme sur les mêmes données produit les mêmes octets — entre l'interpréteur d'édition et le WASM compilé, entre deux exécutions, entre deux machines.

Pourquoi. « À peu près égal » n'est pas une propriété sur laquelle on peut bâtir. La byte-égalité, si : elle rend le rejeu exact, les tests golden significatifs, les résultats reproductibles d'un appareil à l'autre, et la ré-exécution indépendante (par exemple, un serveur revérifiant l'exécution d'un client) tout simplement possible. La virgule flottante est déterministe si et seulement si chaque source de variance est épinglée — donc Flux les épingle toutes, comme politique du langage plutôt que fardeau de l'auteur.

Ce qui est épinglé.

• f64 scalaire, pas de SIMD dans le domaine déterministe, pas de réassociation FP. Le réordonnancement vectoriel et les réductions réassociées changent les bits ; le cœur déterministe de Flux refuse les deux, et l'ordre de réduction est fixe.
• Les transcendantes (log, exp, sin, cos, tan, atan, atan2, pow) passent par une seule build libm épinglée — jamais le Math du moteur hôte, qui diffère légitimement d'un ULP entre moteurs.
• Décimal, Unicode, calendrier, PRNG. Les maths monétaires en virgule fixe, les opérations sur chaînes (unités scalaires Unicode, tables de casse épinglées), l'arithmétique calendaire (données de fuseaux horaires épinglées), et le générateur aléatoire à graine (un PRNG entier basé sur compteur) sont chacun une seule routine partagée, utilisée à l'identique par l'interpréteur, le module compilé et tout ré-exécuteur.
• Un na canonique. Les valeurs manquantes se comparent comme absentes partout, et à chaque frontière de stockage ou de hachage na est forcé à un unique motif de bits — de sorte que deux moteurs ne sont jamais en désaccord sur les octets de « rien ».

L'équivalence n'est pas supposée ; elle est vérifiée à chaque compilation en exécutant l'interpréteur et le module compilé sur des données réelles et en affirmant la bit-égalité (invariant I7). Une divergence bloque l'artefact.

Ce que cela vous apporte.

• Débogage exact au rejeu. Reculez aussi fiablement que vous avancez ; chaque valeur est reproductible à la demande.
• Des tests qui veulent dire quelque chose. Un instantané golden correspond exactement, ou bien le programme a changé. Il n'y a aucune tolérance à régler et aucune instabilité à excuser.
• Accord entre machines. Deux appareils — ou un client et un serveur vérificateur — calculent des résultats identiques, ce qui rend honnêtes les artefacts partagés et la vérification indépendante.

En pratique.

fluxr = math.log(close / close[1])        // ratio in, dimensionless out — via the pinned libm, same bits everywhere
x = rand(42)                     // seeded: deterministic, replayable, admissible in ANALYSIS

L'aléatoire sans graine existe — du côté présentation du pare-feu (pilier 5), où le déterminisme n'est délibérément pas promis.

#4. Kinds dimensionnels

L'énoncé. Chaque flux porte un kind — un type dimensionnel qui enregistre ce que la valeur est physiquement, pas seulement qu'elle est un nombre. Le système de kinds calcule le kind de chaque résultat et rejette les opérations sans signification physique.

Pourquoi. Dans le code analytique, les pires bugs ne sont pas des erreurs de type qu'un vérificateur conventionnel attraperait — tout est un flottant. Ce sont des erreurs de dimension : ajouter un prix à un oscillateur, comparer un volume à un ratio, fournir un pourcentage là où un level est attendu. Tout cela est un non-sens bien typé dans un monde qui ne connaît que les flottants. Flux redonne aux données leur physique. L'axe des prix est modélisé comme un espace affine : price est un point, level est un déplacement (vecteur), ratio est un scalaire sans dimension ; les dimensions forment une algèbre sous les opérateurs. Les conséquences agréables sont des théorèmes, pas des cas particuliers :

fluxrange = high - low                                //   price − price → level  (point − point = vector)
band  = sma(close, 20) + 2 * stdev(close, 20)     //   price + level → price  (point + vector = point)
rel   = close / open                              //   price ÷ price → ratio  (dimensionless)
bad   = close + rsi(close, 14)                    // ✗ [ErrDim] — point + dimensionless: no affine meaning

Ce que cela vous apporte.

• Le non-sens est rejeté à la compilation, avec une explication dimensionnelle et un correctif suggéré — pas un NaN mystérieux trois pas plus loin.
• La présentation est inférée. Le kind est assez riche pour dériver l'affichage : un price se superpose à l'axe des prix ; un osc(0,100) obtient son propre panneau, une échelle fixe et ses lignes de repère ; un signal s'affiche comme des marques. Une ligne de mathématiques se matérialise en un graphique correctement meublé parce que le kind a dit tout ce qu'il fallait.
• L'inférence est silencieuse jusqu'à ce que vous ayez tort. Vous n'annotez rien ; les kinds remontent depuis les sources à travers les opérateurs, chaque expression reçoit son kind le plus précis, et la seule fois où vous entendez parler du système, c'est quand il vous sauve.

Les kinds sont la clé de voûte sur laquelle s'appuient les autres piliers : le planificateur de mémoire dimensionne les tampons à partir des kinds, le modèle de coût de l'optimiseur les lit, et la complétion de l'éditeur filtre par eux. Le système complet — sortes, treillis, coercition, algèbre des opérateurs — est spécifié dans Kinds.

#5. Des plans avec un pare-feu à sens unique

L'énoncé. Le calcul et la présentation sont des plans séparés, et la dépendance ne les traverse que dans une seule direction : la présentation peut lire l'analyse ; l'analyse ne peut jamais lire la présentation. Les violations sont des erreurs à la compilation : [ErrFirewall].

Pourquoi. Un langage qui promet le déterminisme et veut une sortie plaisante, animée, interactive a un problème : les écrans, les horloges murales, les pointeurs et l'aléatoire sont exactement les choses que le déterminisme doit exclure. Les issues habituelles sont sinistres — soit les garanties s'érodent en douce (« surtout déterministe »), soit la couche de sortie est affamée jusqu'à l'inertie. Flux refuse le dilemme structurellement. Tout ce qui est non déterministe — now(), coordonnées d'écran, état de survol, rand/noise sans graine — existe, mais seulement du côté présentation (CANVAS, TRANSITION), où rien en aval ne dépend de l'exactitude. Les plans ANALYSIS et APP restent à l'intérieur des garanties. Le mur entre eux est directionnel et imposé par le compilateur — voir la figure dans Qu'est-ce que Flux.

Ce que cela vous apporte.

• Des garanties qui survivent à la décoration. Un effet animé et aléatoire peut se tenir à quelques pixels d'un signal sans aucune possibilité de le contaminer. Le « no-repaint » tient même dans des programmes pleins d'animation, parce que la dépendance ne peut pas être exprimée.
• La liberté là où c'est sûr. Les auteurs CANVAS obtiennent le temps réel, l'amortissement, les ressorts, le bruit et l'interactivité sans taxe de déterminisme — le plan est honnêtement hors des garanties, et le pare-feu est ce qui rend cette honnêteté abordable.
• Une surface d'audit propre. Le fait qu'un programme soit rejouable est un fait statique à propos du plan dans lequel vivent ses puits, et le compilateur vous le dit.

En pratique.

fluxdot { at:(bar.i, close); r: 4 }       // CANVAS reading an ANALYSIS value — the legal direction
x = ema(now(), 20)                    // ✗ [ErrFirewall] — wall-clock time cannot enter ANALYSIS

La même règle donne à live(e) — la lecture, côté présentation, de l'unité encore en formation — un foyer sûr : elle peut s'écouler vers des puits d'affichage, jamais dans une analyse confirmée. Détails dans Les quatre plans.

#6. Sécurité par capacités

L'énoncé. Les scripts n'ont aucune autorité ambiante. Les effets sont des capacités-objet à refus par défaut : un script ne peut affecter le monde qu'à travers des capacités qu'il a déclarées, que l'utilisateur a accordées, et que l'hôte arbitre.

Pourquoi. Flux est le langage d'une plateforme où le code est partagé, vendu et exécuté par des gens qui ne l'ont pas écrit. Cela n'est tenable que si la sécurité est une propriété du langage et de l'hôte, pas d'un processus de revue. Flux y parvient par couches : le langage n'a aucune primitive qui fasse des E/S — pas de fetch, pas d'accès au DOM, pas d'eval, pas de descripteurs de fichiers — de sorte que le seul canal d'un script vers le monde, ce sont les données qu'il remet à l'hôte. Sur le plan APP, ce canal est explicite :

• Les commandes sont des données inertes. Un Cmd porte des valeurs — un nom de son, une clé de stockage, un score — jamais un token, une URL ou un handle. L'hôte détient chaque ressource et n'exécute la commande que si la capacité correspondante a été déclarée et accordée. Émettre une commande que le manifeste n'accorde pas est rejeté à la compilation ([ErrCapDenied]) — cela ne devient jamais un événement à l'exécution qu'il faudrait attraper.
• Les capacités sont des déclarations, pas des valeurs. Ce sont des entrées nommées namespace:verb dans le descripteur de l'app — chart:read, storage:own, net:fetch — jamais des objets de première classe, donc elles ne peuvent être ni re-déléguées ni amplifiées depuis l'intérieur d'un script.
• Les manifestes s'agrègent transitivement, avec zéro escalade. Le manifeste scellé d'un artefact est l'union des besoins en capacités sur toute sa fermeture de dépendances, intersectée avec l'octroi de l'utilisateur. Le besoin d'une dépendance fait surface dans le manifeste de haut niveau avant l'installation, et aucune dépendance ne peut jamais détenir une capacité que l'utilisateur n'a pas accordée à l'ensemble.

fluxapp quiz {
  capabilities: [ chart:read, sfx, storage:own ]   // everything this app may ever touch
  // ... a Cmd like PlaySfx("ding") is data; the host decides whether it runs
}

Ce que cela vous apporte.

• Le code non fiable comme une routine. Installer un artefact est un consentement éclairé à une liste courte et exacte — pas un acte de foi envers un auteur.
• Pas de députés confus. L'autorité ne circule que le long des arêtes d'import, plafonnée par l'octroi ; une bibliothèque ne peut pas blanchir un accès à travers l'app qui l'embarque.
• Honnêteté first-party. Les propres applications de la plateforme s'exécutent sous le même régime avec les mêmes manifestes — la confiance est un niveau d'octroi, jamais un chemin de code.

#7. Optimisable par construction

L'énoncé. Un programme Flux est un DAG pur, typé, total et causal — la forme sur laquelle les optimisations classiques sont sûres par construction. Et l'optimiseur est vérifié à chaque compilation, jamais cru sur parole.

Pourquoi. Dans les langages impurs, les optimiseurs dépensent leur sophistication à prouver qu'une transformation ne peut pas observer un effet — et abandonnent prudemment quand ils n'y arrivent pas. Les programmes Flux n'ont aucun effet à observer : deux calculs quelconques du même sous-graphe pur sont interchangeables, donc le partage, l'élagage, le réordonnancement et la spécialisation n'exigent aucun exploit héroïque. La taille petite et bornée du programme ajoute un second avantage, inhabituel : les recherches sur le graphe entier, infaisables sur de grands programmes, sont abordables ici, donc l'optimiseur peut viser l'optimal plutôt que le « assez bon ».

Le modèle de confiance est la partie distinctive. L'optimiseur obéit à une seule loi : le programme optimisé doit être bit-identique à la sémantique de référence — l'évaluation canonique du DAG non optimisé (ou le noyau natif, pour les primitives intégrées). Cette loi est imposée par la validation de traduction : chaque compilation exécute les artefacts de référence et optimisé sur des données réelles et affirme la byte-égalité. L'optimiseur peut donc être agressif précisément parce que personne n'a à y croire — une compilation erronée ne peut pas être livrée, elle ne peut qu'échouer bruyamment au gate.

Ce que cela vous apporte.

• Partage gratuit. L'élimination des sous-expressions communes est globale : écrivez ema(close, 26) à quatre endroits dans un script et c'est calculé une seule fois. Post-v1. Le partager entre quatre scripts co-actifs — un seul graphe fusionné pour tout le graphique — est un palier d'optimiseur ultérieur.
• Un coût que vous pouvez voir. Le code mort est éliminé, les constantes pliées, les chaînes élément par élément fusionnées ; la gouttière de coût de l'éditeur montre le graphe optimisé, donc ce que vous lisez est ce que vous payez.
• Un défaut sûr et une voie rapide étiquetée. Le défaut est bit-exact, toujours. Post-v1. La virgule flottante relâchée (réassociation, fused multiply-add) est conçue comme un opt-in explicite et étiqueté — jamais un défaut silencieux, et jamais bit-exact.

En pratique.

fluxdef ema0(s, n) = let a = 2/(n+1) in scan(s, (p) -> a*s + (1-a)*p)
def macd0(s)   = let l = ema0(s, 12) - ema0(s, 26) in { macd: l, signal: ema0(l, 9), hist: l - ema0(l, 9) }

plot macd0(close).macd, macd0(close).signal    // two calls, one shared subgraph — CSE, verified bit-exact

Les paliers, le modèle de coût et le harnais de validation sont spécifiés dans Optimiseur.

#Comment les piliers se composent

Les piliers ne sont pas sept fonctionnalités indépendantes ; chacun s'appuie sur les autres, et l'ensemble des garanties tient parce que la boucle se referme :

• La totalité rend la vérification possible. Chaque analyse statique du langage — inférence de kind, vérification de causalité, exhaustivité, l'oracle de validation de l'optimiseur — se termine parce que les programmes sont totaux et que leurs bornes sont des constantes. Un langage avec des programmes non bornés ne pourrait garantir l'achèvement d'aucune de ses vérifications.
• La causalité fait du graphe un DAG, ce que l'inférence de kind parcourt en une passe, ce que l'ordonnanceur parallélise sans verrous, ce que le débogueur met en point de contrôle et rejoue, et ce que l'optimiseur réordonne sans risque. Un seul théorème d'acyclicité, consommé de quatre façons.
• Le déterminisme a besoin de la totalité et de la causalité — le rejeu n'est exact que si les programmes se terminent et que l'historique est immuable — et a besoin du pare-feu, qui garde le temps réel et l'aléatoire hors du domaine déterministe au lieu de demander aux auteurs d'être prudents.
• Les kinds alimentent tout. L'inférence de présentation (pilier 4), le plan mémoire qui rend les budgets statiques (pilier 1), la classification des puits par le pare-feu (pilier 5) et le modèle de coût de l'optimiseur (pilier 7) lisent tous les mêmes faits dimensionnels.
• La sécurité par capacités repose sur la totalité et la pureté. Le refus par défaut serait du théâtre si un script pouvait boucler indéfiniment, atteindre des E/S ambiantes, ou cacher des effets dans l'ordre d'évaluation. Parce qu'il ne peut faire aucune de ces choses, le manifeste de capacités est réellement l'histoire complète de ce qu'un artefact peut faire.
• La liberté de l'optimiseur est le dividende du déterminisme. « Bit-identique à la référence » n'est une loi utilisable que parce qu'une réponse de référence existe — déterministe, stable à l'octet, sur chaque machine. En échange, l'optimiseur rembourse le budget que la totalité avait promis : le coût que le compilateur a déclaré est le coût que vous observez.

Retirez un seul pilier et les autres s'affaiblissent ; ensemble, ils se referment : décrivez une expression, et le moteur peut l'évaluer — se terminant de façon prouvée, ne réécrivant jamais l'historique, identique partout, divulguant tout ce qu'elle touche, à un coût connu à l'avance.

#Voir aussi

• Qu'est-ce que Flux — le modèle mental et les quatre plans en un coup d'œil.
• Premiers pas — les piliers tels que vous les vivez en écrivant.
• Les quatre plans — le pare-feu en profondeur.
• Kinds — le système dimensionnel derrière le pilier 4.
• Temps et état — délais, horloges, scan et causalité derrière le pilier 2.
• Garanties — chaque promesse et la vérification machine qui l'impose.

Premiers pas

Ce chapitre est une première session guidée. Elle commence par le plus court programme qui fait quelque chose de réel, et le fait grandir — paramètres, style, composition, état, horloges multiples, une scène en mouvement, une petite application — en expliquant ce que le langage a fait pour vous à chaque étape et, tout aussi important, ce qu'il a refusé de faire.

Tout ici est un programme complet. Collez n'importe lequel dans l'éditeur et il s'exécute.

#Une ligne

fluxplot rsi(close, input(14))

C'est un analytique complet et publiable. Rien n'a été configuré, et pourtant :

• close est un price. rsi est une famille d'oscillateurs bornés, donc l'expression a le kind osc(0,100).
• Parce que le kind est un oscillateur borné, il ne peut pas partager l'axe des prix — il obtient son propre panneau, avec une échelle 0–100 fixe et une ligne médiane. Parce que l'opération est spécifiquement rsi, ses repères conventionnels 30/70 sont tracés aussi.
• Parce que vous avez écrit input(14), un contrôle de paramètre apparaît, typé et doté d'une plage.
• Parce que le programme est causal et total par construction, il est aussi rejouable, borné, et byte-identique sur chaque moteur — ce que le panneau des garanties vous dira sans qu'on le lui demande.

Supprimez input(…) et écrivez plot rsi(close, 14) : même analytique, pas de contrôle. L'enveloppe input est la façon dont une valeur devient un bouton de réglage.

Ce qui vient de se passer. Vous n'avez choisi ni panneau, ni échelle, ni couleur, ni ligne de référence. Le kind de l'expression a tout porté. C'est la plus grande conséquence ergonomique d'un système de types dimensionnel, et elle vaut pour tout ce que vous écrirez ensuite.

#Paramètres et style

input accepte une valeur par défaut, une plage optionnelle, et des métadonnées optionnelles :

fluxlen  = input(14, 2..200, title: "Length")
src  = input(close, title: "Source")
show = input(true, title: "Show band")

plot rsi(src, len)

Le kind de la valeur par défaut décide du widget : un nombre donne un champ numérique (une plage en fait un curseur), close donne un sélecteur de source, true donne une case à cocher, une liste de chaînes donne une énumération.

Les défauts de présentation sont inférés, mais l'intention gagne toujours :

fluxm = macd(close)
plot m.hist { style: histogram, color: if m.hist > 0 then up else down }
plot m.macd, m.signal
plot ema(close, 200) { overlay }        // it is already a price — this is explicit
plot rsi(close, 14) { guides: [20, 80] } // your own reference lines, kind-checked

Les valeurs de style forment un ensemble fermé (histogram, columns, stepline, area, circles, cross) ; une ligne est le défaut qu'un level ou un price infère. Forcer un level sur le graphique avec { overlay } lui donne son propre axe secondaire — le compilateur sait qu'une échelle de prix partagée l'aplatirait à néant.

#Composition

def définit une fonction pure de flux vers flux. Elle est inlinée dans le graphe, il n'y a donc aucun coût d'appel à considérer :

fluxdef zscore(x, n = 20) = (x - sma(x, n)) / stdev(x, n)

plot zscore(close)          // (price − price) ÷ level = level ÷ level → ratio
plot zscore(hlc3, 50)       // the same def on another price source — the kinds follow the argument

Toute fonction peut s'écrire comme une chaîne façon méthode — le receveur devient le premier argument — ce qui est la manière dont la plupart des gens finissent par écrire des analytiques :

fluxsmoothRsi = close.ema(20).rsi(14)     // ≡ rsi(ema(close, 20), 14)

Le gain n'est pas la brièveté. Après avoir tapé close., l'éditeur ne propose que les fonctions dont le premier paramètre accepte un price — le système de types devient un mécanisme de découverte.

Plusieurs noyaux renvoient un enregistrement, et vous projetez le champ voulu :

fluxbb = bollinger(close, 20, 2)
plot bb.upper, bb.middle, bb.lower
fill bb.upper..bb.lower      // a band: both operands are `price`, so the fill is well-formed

fill bb.upper..rsi(close,14) serait ✗ [ErrDim] — vous ne pouvez pas ombrer la région entre un prix et un oscillateur sans dimension, et le langage le dit plutôt que de dessiner un non-sens.

#Signaux, marques et alertes

Une comparaison produit un signal, et un signal est présenté comme des marques — jamais comme une ligne :

fluxcross = close cross_up ema(close, 50)

mark cross "crossed at {fmt.price(close)}"
alert cross "EMA-50 crossed up"

Les chaînes s'interpolent, de sorte qu'une étiquette ou un message d'alerte peut porter des valeurs en direct. cross_up est un opérateur infixe : il est vrai sur la barre où le côté gauche franchit le côté droit vers le haut, et sa définition — comme tout le reste — ne lit que des données clôturées.

#État

Vous n'écrivez jamais de boucle sur les barres. Quand une valeur dépend de son propre passé, vous écrivez un scan : une graine, et un pas qui reçoit l'état précédent.

flux// a running maximum since the start
def runMax(x) = scan(x, (prev) -> math.max(prev, x))

// a trailing stop that only ever ratchets upward while long
def trail(mult) =
  let stop = close - mult * atr(14) in
  scan(stop, (prev) -> math.max(prev, stop))

plot trail(3)               // price − lit × level = price → it overlays

La fonction de pas voit prev — l'état à la barre précédente — et les valeurs de la barre courante. C'est tout le modèle : l'état avance d'un pas par barre, à travers un délai unitaire, ce qui est précisément pourquoi une valeur une fois émise ne peut jamais être réécrite.

Un état composite est un enregistrement, et une machine à états est un variant plus un match :

fluxvariant Trend { Up | Down }

def step(p, n) = match p.dir {
  Up   -> if close < p.ref - atr(n) then { dir: Trend.Down, ref: close } else p
  Down -> if close > p.ref + atr(n) then { dir: Trend.Up,   ref: close } else p
}

def flip(n) = scan({ dir: Trend.Up, ref: close }, (p) -> step(p, n))

match est l'éliminateur d'un variant, et il doit couvrir chaque constructeur — un cas non couvert est [ErrTotalMatch], une erreur de compilation, pas une surprise à l'exécution.

#Plus d'une horloge

L'axe de pas d'une série est une valeur, de kind clock. @ lit une expression sur une autre horloge, et il n'en lit que les unités clôturées :

fluxplot ema(close, 20) @ tf("1h")                 // hourly EMA, shown on whatever chart you are on
color bars: if close > ema(close, 50) @ tf("1d") then up else down

Cette seconde ligne est l'idiome de confluence : un graphique rapide, coloré par une tendance lente. Ce n'est pas une fonctionnalité spéciale — c'est le rééchantillonnage ordinaire, et il est causal, donc ce qu'une barre montrait hier, elle le montre encore aujourd'hui.

Les axes de pas pilotés par le prix sont aussi des horloges (renko(box), pnf(box, rev), range(r)), ce qui explique pourquoi les représentations de graphique alternatives ne sont pas un sous-système séparé : ce sont une horloge différente.

#Une scène qui bouge

La présentation vit sur son propre plan, où chaque propriété est un signal — une constante, une valeur de données et une animation sont la même sorte de chose, il n'y a donc pas d'API d'animation à apprendre :

fluxcircle {
  at:    (bar.i, spring(close)),   // the position eases toward the data
  r:     6,
  glow:  16,
  trail: 24
}

on close cross_up highest(close, 250)[1] -> burst(40) ring { r: 6 -> 24, life: 2s }

La scène peut lire des valeurs d'analyse. L'analyse ne peut pas lire la scène — cette règle à sens unique est ce qui empêche les parties mobiles de jamais toucher les nombres. Essayez-le et vous obtenez [ErrFirewall], avec une explication.

#Une petite application

Le quatrième plan ajoute un état qui persiste entre les événements et décide ce qui est affiché — un modèle, une update pure, une view pure, et des souscriptions déclaratives. Les effets sont des données inertes que l'hôte exécute ; les capacités sont à refus par défaut.

fluxvariant Msg { Tick | Reset }

app counter {
  capabilities: [ ]

  init(p)          = { n: 0 }
  update(m, msg)   = match msg {
                       Tick  -> { model: m with { n: m.n + 1 }, cmds: [] }
                       Reset -> { model: m with { n: 0 },       cmds: [] }
                     }
  view(m)          = row {
                       text("count: {m.n}")
                       button("reset", Reset)
                     }
  subs(m)          = [ OnTick(1000, Tick) ]
}

OnTick(1000, Tick) se lit « chaque seconde, applique le constructeur Tick ». Une souscription porte le constructeur dans lequel l'hôte enveloppera sa charge utile — c'est ainsi qu'un événement sait à quelle branche d'update il appartient, sans qu'aucune valeur de fonction n'entre jamais dans le langage.

update est pure et totale : elle ne peut pas lire l'horloge, ne peut pas atteindre le réseau, et doit gérer chaque message. Tout ce qui est ambiant — temps, aléatoire, données, entrée — arrive sous forme de message, ce qui est exactement pourquoi une application peut être rejouée message par message et pourquoi ses tests sont des goldens sur des fonctions pures.

#Ce que fait l'éditeur pendant que vous tapez

Complétion filtrée par kind après ., une carte de survol avec la signature et une sparkline en direct de l'expression sur les données courantes, des diagnostics avec correctifs rapides, un aperçu qui réévalue la partie typable de votre programme à chaque frappe (un nom à moitié tapé laisse une seule valeur en blanc, jamais l'écran), et une vue dataflow qui répond « pourquoi ce signal est-il vrai ici ? ». Voir l'éditeur.

#Voir aussi

• Les quatre plans — le pare-feu en profondeur, et à quoi sert live().
• Kinds — le système de types qui a produit chaque défaut ci-dessus.
• Temps et état — délais, fenêtres, scan, horloges, préchauffe.
• Inférence — la table de présentation, les surcharges, le catalogue d'erreurs.
• Livre de recettes — des recettes qui marchent à travers chaque plan.
• Vue d'ensemble du FDK — les bibliothèques : compute, collections, text, net, display.

Les quatre plans

Un programme Flux n'est pas une seule sorte de chose. Calculer un indicateur, dessiner une comète qui suit le prix, faire morpher un graphique quand l'asset change, et faire tourner une application à état dans un panneau sont quatre activités différentes avec quatre horloges différentes et quatre jeux de règles différents. La plupart des langages vous donnent un seul plan et vous demandent d'être prudent. Flux vous en donne quatre, et fait de la frontière entre eux une propriété du système de types.

Le gain est une phrase qui vaut la peine d'être lue deux fois : une valeur peut être animée, aléatoire et dépendante de la frame, tout en restant, de façon prouvée, incapable de changer un nombre calculé. Pas par convention. Par construction.

Une note sur les exemples. Flux n'a pas d'expressions-instructions, donc une expression nue n'est pas un programme. Les lignes marquées ✗ sur cette page sont donc des fragments d'expression : ils existent pour montrer ce que les règles de kind refusent, pas ce que l'analyseur accepte. Chaque ligne non marquée est une instruction légale.

#ANALYSIS — le plan qui calcule

Le plan d'analyse est le plus contraint, et donc le plus digne de confiance. Tout ce qui s'y trouve est une fonction pure du passé : les délais ne regardent qu'en arrière, le rééchantillonnage ne lit que les unités clôturées, la rétroaction doit traverser un délai unitaire. Ce qui suit n'est pas une promesse mais un théorème — une valeur, une fois produite pour une barre, ne peut jamais changer.

fluxplot rsi(close, 14)
plot ema(close, 20) @ tf("1h")            // a coarser clock — still causal
mark close cross_up ema(close, 50)

L'analyse ne lit rien des plans au-dessus d'elle. Il n'y a aucun symbole pour la souris, pour l'horloge murale, pour la frame courante, ou pour savoir si le mode 3D est activé. Pas « c'est une mauvaise pratique » — ces noms n'existent pas dans l'espace de noms de l'analyse.

#CANVAS — le plan qui montre

Le plan canvas peut lire l'analyse. Il ne peut pas l'écrire.

fluxcircle {
  at:    (bar.i, spring(close)),   // reads analysis; the easing is cosmetic
  glow:  16 + 8 * throb(0.4),      // per-frame, time-only — the compositor owns it
  trail: 24
}

on close cross_up highest(close, 250)[1] -> burst(40) ring { life: 2s }

Chaque propriété est un signal — une constante, une valeur de données et une animation sont ici la même sorte de chose, il n'y a donc pas d'API d'animation à apprendre. Et parce que le compilateur sait quels signaux sont pilotés par le temps, il les route vers le compositeur de l'hôte : zéro JavaScript par frame pour les parties qui bougent le plus.

#TRANSITION — le plan qui interpole

fluxon switch(asset) -> morph chart over 500ms { ease: inOutCubic ; stagger: 0.3 }
on click        -> focus(view, at: (bar.i, close), zoom: 2.0, over: 600ms)

La valeur de stabilisation d'une transition — l'endroit où elle atterrit — est une donnée d'analyse et vit dans l'oracle. Sa trajectoire — la façon dont elle y arrive — est cosmétique et n'y vit pas. C'est pourquoi prefers-reduced-motion peut sauter directement à l'état final et ne rien changer du tout dont dépende un quelconque verdict.

#APP — le plan qui se souvient

Post-v1. Le plan APP est scellé dans la conception et additif au cœur ; son déploiement suit le langage v1.

Les trois autres plans ne peuvent pas détenir un état qui persiste entre les événements et décide ce qui est affiché. Le plan APP ajoute exactement cela, et le paie avec une recette stricte : tout ce qui est ambiant — temps, entrée, aléatoire, réseau, valeurs d'analyse — arrive sous forme de message, et le journal de messages est l'unique source de vérité. C'est ce qui rend une application rejouable, testable sans mock, et ré-exécutable par un serveur bit pour bit.

Voir Plan APP pour le contrat complet.

#Le pare-feu

Une seule règle tient toute la conception ensemble :

Les flèches de dépendance ne pointent jamais vers une garantie plus faible.

La présentation peut lire l'analyse. L'analyse ne peut jamais lire la présentation. Le plan APP peut lire l'analyse (en lecture seule, via une souscription typée) et peut orchestrer la présentation (via des commandes) — mais il ne peut jamais écrire l'analyse non plus.

   APP  (mutable state + effects)          ← the most permissive plane
    │  reads ANALYSIS  (Sub OnSeries)              ✔ read-only
    │  orchestrates CANVAS / TRANSITION  (Cmd)     ✔
    ▼
 CANVAS / TRANSITION  (cosmetic, per frame)       ← reads ANALYSIS ✔
    ▼
 ANALYSIS  (pure, causal, no-repaint)             ← reads nothing above it ✘

Ce que le pare-feu interdit réellement est précis. Voici les valeurs qui ne peuvent jamais s'écouler dans l'analyse :

Tous les quatre lèvent [ErrFirewall], à la compilation, avec une explication plutôt qu'une réprimande.

Pourquoi cela mérite une séparation de plans plutôt qu'un lint. Une discipline dont vous devez vous souvenir est une discipline que vous oublierez à 2 heures du matin sous la pression d'une échéance. Un pare-feu imposé par le système de kinds en est un que vous ne pouvez pas oublier : le nom n'est pas dans la portée, et le compilateur ne laissera pas la valeur traverser. C'est ce qui rend sûr d'exécuter la scène animée, aléatoire et interactive d'un inconnu juste à côté du nombre sur lequel repose votre décision.

#live() — la seule exception, et pourquoi elle est sûre

Les traders veulent voir un indicateur se mettre à jour à l'intérieur de la barre en formation. Cette lecture est réellement utile et réellement non causale, donc Flux lui donne un nom, un plan, et un mur :

fluxplot live(ema(close, 20))          // ✓ display — the forming bar included, per frame
alert live(ema(close, 20)) > 100   // ✗ [ErrFirewall] — a decision may not read a forming value
rsi(live(close), 14) > 70          // ✗ [ErrFirewall] — analysis may not consume one either

live(e) réévalue le sous-graphe d'analyse de e en incluant la barre en formation, à chaque frame. Son résultat ne peut s'écouler que vers des puits d'affichage (plot, mark, fill, color bars, une scène). Tout puits confirmé — une alerte, une assertion, une valeur qu'un calcul consomme — est [ErrFirewall].

Notez où live se place, car les deux emplacements ne sont pas des variations sur un même thème. Il enveloppe l'expression dont le sous-graphe doit être réévalué : live(ema(close, 20)) demande la moyenne incluant la barre en formation, et atterrit dans un puits d'affichage. Poussé vers l'intérieur, sur l'argument d'un noyau — ema(live(close), 20) — il cesse d'être une requête d'affichage et devient une valeur en formation remise à un calcul, ce qui est la brèche elle-même. Le pare-feu se moque qu'un plot attende à l'autre bout : le noyau d'analyse l'a déjà consommée.

Trois conséquences, qui comptent toutes :

• La série confirmée de e reste byte-identique. live() ajoute une vue provisoire ; il ne modifie pas ce qui a été calculé.
• live() est exclu de l'oracle de byte-identité, exactement comme l'horloge murale — de sorte que la garantie que les deux moteurs concordent est intacte.
• Un script qui l'utilise est marqué non rejouable dans le panneau des garanties. Vous voyez le compromis que vous avez fait.

C'est la forme générale de chaque échappatoire dans Flux : la nommer, la borner, la murer, et montrer à l'utilisateur ce qu'elle a coûté.

#Sur quel plan suis-je ?

Vous n'en déclarez jamais un. Le plan est inféré de ce que vous écrivez — c'est tout l'intérêt de « écrivez les maths, la machinerie suit » :

Et si vous essayez de les mélanger d'une façon que le pare-feu interdit, le compilateur vous dit quelle valeur a franchi quelle ligne, et quoi faire à la place.

#Voir aussi

• Plan APP — le contrat applicatif complet.
• Canvas — signaux, espaces, événements, primitives, le modèle de performance.
• Transitions — morph, replay, focus, et le descripteur de transition.
• Temps et état — causalité, horloges, live() en profondeur.
• Garanties — ce que chaque plan promet, et comment c'est vérifié.
• display — les deux strates, et où s'arrête le déterminisme de présentation.

Structure lexicale

Cette page définit comment un texte source Flux devient un flux de tokens : le modèle de source, les commentaires, le saut de ligne significatif, le catalogue complet des tokens (identifiants, la famille numérique et ses suffixes collés, chaînes et interpolation, références de capacités, opérateurs et ponctuation), et le modèle de mots-clés — quels mots sont réservés, où, et pourquoi la plupart ne sont réservés que contextuellement. Tout ce qui vient ensuite — la grammaire, l'inférence de kinds, l'éditeur — consomme exactement le flux de tokens spécifié ici.

Deux propriétés cadrent tout le chapitre. D'abord, le lexer est total : tout texte en entrée produit un flux de tokens (une entrée mal formée se manifeste par des diagnostics précis, jamais par un crash). Ensuite, le lexer est linéaire et incrémental : chaque dispositif dépendant du contexte ci-dessous (le saut de ligne significatif, l'interpolation, les références de capacités, la consommation numérique) est borné par des compteurs que le lexer maintient déjà, de sorte que retokeniser après une édition ne touche que le voisinage édité — la propriété qui maintient l'aperçu en direct dans son budget de frame.

#Modèle de source

Un programme Flux est un texte Unicode. L'alphabet fixe du langage lui-même — identifiants, mots-clés, opérateurs, ponctuation — est en ASCII ; le texte arbitraire (tout Unicode) vit à l'intérieur des littéraux de chaîne et des commentaires. Entre les tokens, espaces et tabulations sont insignifiants et peuvent apparaître en nombre quelconque ; les sauts de ligne sont significatifs (voir TERM ci-dessous).

Une règle façonne de nombreux diagnostics de cette page : Flux n'a pas de juxtaposition. Deux expressions primaires adjacentes sans opérateur entre elles ne forment jamais un terme :

fluxx = 1.50 d      // ✗ syntax error — NUMBER then IDENT: two adjacent primaries
y = 1.50d       // decimal(2) — the glued suffix makes this ONE token
d = 2           // `d` alone is an ordinary identifier — a licit binding
z = 1.50 * d    // valid — the detached `d` is just a name here

Parce que l'adjacence n'a jamais de sens, le lexer peut se permettre des tokens de suffixe collés (1.50d, 4px) sans ambiguïté : soit le suffixe touche le nombre et la paire est un seul token, soit ce n'est pas le cas et le programme est mal formé à moins qu'un opérateur n'intervienne.

Un script peut s'étendre sur plusieurs fichiers source .flux ; le modificateur de visibilité package (voir grammaire — modules) est cantonné exactement à cet ensemble de fichiers.

#Commentaires

flux/// z-score of a series over n bars
def zscore(x, n=20) = (x - sma(x, n)) / stdev(x, n)

plot zscore(close, 20) as z   // an ordinary comment

Un doc-commentaire est lexicalement un commentaire (le parser l'ignore) mais il n'est pas jeté : le pipeline de documentation collecte le bloc /// qui précède un def et le publie comme la documentation au survol de la définition et son entrée doc-as-data (voir l'éditeur). Il n'y a pas de commentaires de bloc ; un commentaire se termine toujours au saut de ligne. Les commentaires sont transparents aux règles de saut de ligne significatif ci-dessous — une ligne qui se termine par un commentaire // … en fin de ligne est classée par le dernier token avant le commentaire, et une ligne uniquement de commentaire ne termine ni ne prolonge une instruction.

#Le saut de ligne significatif (TERM)

Flux n'a pas de terminateur d'instruction obligatoire. Une instruction se termine à la fin de sa ligne — le lexer émet un token TERM au saut de ligne — sauf si la ligne est visiblement inachevée. Les points-virgules sont des séparateurs optionnels (jamais requis) ; écrire plusieurs instructions sur une ligne avec ; est licite, mais le Flux idiomatique est d'une instruction par ligne.

Un saut de ligne n'émet pas de TERM (l'instruction continue) quand l'une des trois clauses est vraie :

1. (a) Parenthèse ou crochet ouvrant. La profondeur d'imbrication ( / [ est supérieure à zéro. À l'intérieur des parenthèses et des crochets, les sauts de ligne sont du pur blanc — c'est ainsi qu'un long appel se répartit sur plusieurs lignes. Les accolades ne réinitialisent pas cette profondeur : un corps entre accolades écrit à l'intérieur d'un appel est toujours à une profondeur > 0, donc ses éléments ont besoin d'un séparateur explicite , ou ;. À la profondeur zéro, un saut de ligne sépare les éléments, ce qui explique qu'un record ou un match multi-ligne au niveau supérieur n'a besoin d'aucune virgule :

   fluxdef f(r) = r.a + r.b
   m = { a: 1                      // depth 0 — the newline separates
         b: 2 }
   n = f({ a: 1 ; b: 2 })          // inside a call — the `;` is REQUIRED
   

2. (b) La ligne est en attente. Le dernier token significatif de la ligne est un opérateur, un délimiteur ouvrant, un séparateur, ou un mot-clé qui attend grammaticalement un opérande — if, then, else, let, in, not, and, or, as, from, with, over, def, match, variant, record, app, import, type, representation, tool, on, every, when, tween, spawn, burst, emit, rate, set, morph, replay, focus, cross_up, cross_down, pub, private, package, scene. Un mot-clé contextuel ne compte ici que dans son rôle de mot-clé : dans x = p.on, le on final est un nom de champ et l'instruction se termine. (Une subtilité lexicale : un % final collé à un chiffre est un littéral pourcentage, pas un modulo en attente — 50% termine la ligne.)

3. (c) Le token suivant est un continuateur. Le premier token de la ligne suivante ne peut qu'étendre une expression, jamais commencer un nouvel élément.

La clause (c) n'est pas une liste ad hoc. Définition normative : un token est un continuateur ssi il n'appartient à aucun ensemble FIRST d'un quelconque élément de liste — formellement, ssi il est hors de ⋃ FIRST(item) pris sur chaque production de liste répétée de la grammaire (instructions, enfants de vue, constructeurs de variant, hooks de representation et de tool, bras de match, champs de record, références de capacités, membres d'app). L'ensemble est calculé à partir de la grammaire, pas maintenu à la main, ce qui rend la règle vérifiable par machine et la maintient pour toujours en phase avec la grammaire.

À titre d'illustration, les continuateurs sont les tokens purement infixes ou postfixes — . (accès membre), .., @, +, *, /, %, <, >, <=, >=, ==, !=, cross_up, cross_down, and, or, ->, with, ?, ??, ?., :, ,, ;, les fermeurs ) ] }, le séparateur de variant | — et les mots-clés purement médians then, else, in, as, from.

Trois tokens ne sont délibérément pas des continuateurs bien qu'ils puissent étendre une expression, parce qu'ils peuvent aussi commencer un nouvel élément : - (moins unaire), [ (un littéral de liste) et ( (une forme parenthésée). Un . en tête n'est un continuateur que s'il n'est pas suivi d'un chiffre — .upper continue, mais .5 est un nombre et commence un élément. Pour continuer d'une ligne à l'autre sur l'un de ces tokens ambigus, terminez plutôt la ligne précédente en attente (clause b) :

fluxu = bollinger(close, 20)
  .upper                      // `.` continues the postfix chain — clause (c)

total = close
  + open -                    // `+` continues (c); trailing `-` leaves the line pending (b)
  low

cond = if close > open
  then 1
  else 0                      // medial keywords are continuators — clause (c)

variant Wide { A | B
  | C }                       // `|` is a continuator inside the declaration

multi = sma(
  close,
  20)                         // clause (a): inside ( ) newlines are whitespace

m = { a: 1 }
updated = m
  with { a: 2 }               // `with` is a continuator — postfix record update

L'idiome de la clause (b) pour les têtes ambiguës : a -⏎ b (la ligne se termine sur l'opérateur), v[⏎ i] (la ligne se termine sur l'ouvreur). De même, over n'est pas un continuateur — en tant que mot-clé contextuel, il peut commencer un élément (par exemple comme clé de propriété) — donc un morph … over d multi-ligne se coupe après over, qui est un mot en attente au titre de la clause (b).

Pourquoi cette règle existe. Une syntaxe sans terminateur se lit comme la notation que les auteurs esquissent réellement, mais elle ne doit jamais devenir une devinette sur les blancs. Les trois clauses sont décidables avec au plus un token de lookahead et les compteurs que le lexer porte déjà, de sorte que la classification des sauts de ligne est en O(1) par ligne, linéaire sur le fichier, et incrémentale sous les éditions. Et parce que l'ensemble des continuateurs est défini comme le complément de l'ensemble calculé des têtes d'éléments, il n'y a aucune liste curée à la main qui se désynchronise quand la grammaire grandit : ajouter une tête d'instruction la retire automatiquement des continuateurs.

#Catalogue des tokens

L'inventaire complet des tokens. Chaque classe est détaillée dans les sections qui suivent.

#Identifiants

IDENT = [A-Za-z_] [A-Za-z0-9_]*

Les identifiants sont en ASCII : une lettre ou un underscore, puis des lettres, chiffres et underscores. Un identifiant est un nom pour une liaison, un paramètre, un champ, un kind, une étiquette d'argument, un module ou une déclaration. L'underscore seul _ est lexicalement un identifiant ordinaire avec deux rôles bénis que lui confèrent la grammaire et l'élaborateur : le motif joker dans les bras de match, et le placeholder implicite à paramètre unique en position d'expression (vec.map(_ * 1.1), voir operators).

Le fait qu'un identifiant donné soit disponible dépend du modèle de mots-clés ci-dessous — la plupart des mots-clés de Flux sont contextuels, donc des mots comme render, view ou color restent utilisables comme noms de champs, paramètres et noms de kinds.

#Nombres

NUMBER = ( digits "." digits | "." digits | digits ) [ ("e"|"E") ["+"|"-"] digits ]

42, 2.5, .5 et 1.5e3 sont tous des tokens NUMBER. Un NUMBER nu a le kind lit — le littéral replié en constante (const-folded) qui est polymorphe en dimension (close + 10 est un price ; voir kinds).

Maximal munch, borné par la règle du point. Le scanner de nombres ne consomme jamais un . suivi d'un autre . ou d'un non-chiffre. Cette seule règle fait que les ranges et l'accès membre se composent avec les nombres sans séparateurs :

fluxlen   = input(14, 2..200)      // NUMBER RANGE NUMBER — the dot is never eaten before `..`
half  = .5                     // a leading-dot NUMBER
band  = (2.5..3.5)             // NUMBER RANGE NUMBER — a range lives in its own slots
u     = bollinger(close, 20).upper   // `.upper` is member access, not a malformed number
sci   = 1.                  // exponent form
neg   = -0.5                   // unary minus applied to NUMBER (the sign is not part of the token)

#Littéraux suffixés

Six classes de littéraux portent leur unité comme un suffixe collé au nombre (sans espace) ; SPAN seul accepte aussi exactement un espace. Chaque token est typé à la position d'expression par la règle [LitTyped] du système de kinds :

fluxb  = 300s + 20ms               // duration arithmetic
c  = 50%                       // ratio
d  = 4px                       // screen-space size (CANVAS styling)
r  = 40/s                      // emission rate
sp = life(200 bars)            // barspan — unifies every(n bars) and life: n bars
a  = 1.50d                     // decimal, scale 2 — exact money arithmetic

La règle du d collé (représentative de toute la famille). Le suffixe d doit toucher le nombre, et le caractère après le suffixe ne doit pas prolonger un identifiant :

fluxa = 1.50d       // DEC(1.50, scale 2) — one token
b = 1.      // DEC — the suffix composes with scientific notation
c = 1.50 d      // ✗ syntax error — NUMBER IDENT, two adjacent primaries (no juxtaposition)
d = 2           // a detached `d` is an ordinary identifier — a licit binding
d2 = 1.50 * d   // valid — 1.50 times the bound `d`

Le même contrôle de frontière protège chaque suffixe : 2se n'est pas un DUR (le e final prolongerait un identifiant, donc le lexer produit NUMBER(2) puis IDENT(se), ce que le parser rejette comme juxtaposition), et 40/sec n'est pas un RATE (c'est 40 / sec, une division par l'identifiant sec). L'échelle (scale) du DEC est le nombre de chiffres décimaux écrits : 1.50d est decimal(2), 2d est decimal(0).

Pourquoi des suffixes collés. Les unités sur les littéraux auraient pu être des tokens séparés (1.50 d) ou des appels de constructeur (dur(300)), mais les deux écritures placent une analyse entre le nombre et son unité, et le mot détaché entrerait en collision avec des identifiants ordinaires — d, s et bars sont tous des noms de liaison raisonnables. Coller rend l'unité partie du token, de sorte que la décision est prise par le lexer sans aucun impact sur la grammaire : 1.50d ne peut jamais être mal lu, d seul n'est jamais volé à l'auteur, et chaque littéral arrive à l'inférence en portant déjà son kind. Le seul relâchement — 200 bars avec un seul espace — est accepté parce que bars y est une tête réservée et que la forme span se lit comme de la prose dans les positions every(…) et life:.

Décision ouverte. Le plan conserve SPAN, PX, RATE et l'opérateur binaire % en v1 et les signale pour ratification finale ; ils sont documentés ici comme conservés.

#Chaînes

STRING = '"' frag '"' | "'" frag "'"

Les deux délimiteurs sont équivalents — Flux n'a pas de type caractère, donc l'apostrophe est libre d'être un délimiteur de chaîne. Un littéral de chaîne a le kind string et doit se fermer sur la ligne où il s'est ouvert (un saut de ligne brut dans une chaîne est une erreur de syntaxe). À l'intérieur d'une chaîne, un antislash rend le caractère suivant littéral : \" dans une chaîne "…", \{ et \} pour des accolades littérales (voir interpolation ci-dessous).

fluxplain  = "no interpolation"
single = 'quote style'
alert close cross_up open "crossed"       // strings feed the text channels (labels, messages)

Les chaînes sont des valeurs du kind catégoriel string — du texte borné et immuable pour les étiquettes, les invites et les messages. Elles ne sont jamais tracées comme une série, et + sur deux chaînes concatène (la seule surcharge catégorielle de + ; voir operators).

#Interpolation de chaînes

Un { dans une chaîne ouvre un trou d'interpolation contenant une expression Flux complète. Lexicalement, le littéral est découpé en tokens fragments :

STR_HEAD = '"' frag '{'          (opening fragment — also with ' delimiter)
STR_MID  = '}' frag '{'          (middle fragment)
STR_TAIL = '}' frag '"'          (closing fragment)
interpStr = STR_HEAD expr { STR_MID expr } STR_TAIL

Une chaîne ne contenant aucun { non échappé reste un token STRING atomique. \{ et \} dénotent des accolades littérales à l'intérieur d'un fragment. Le tokeniseur d'interpolation apparie son délimiteur fermant à l'ouvrant ("…" ou '…'), et le { d'un fragment ouvre un mode de lexer borné par le compteur d'accolades que le lexer tient déjà — de sorte que les trous s'imbriquent à n'importe quelle profondeur où le programme lui-même peut s'imbriquer, et la tokenisation reste linéaire et incrémentale.

fluxm = { a: 0 }
x = close
mark close > open "close {close} above {str(open)}"
label  = "nested {(m with { a: 1 }).a} brace"    // a full expression, inner braces counted
single = 'quote {x} style'                 // interpolation works in '…' too
lit    = "a literal \{brace\}"             // escaped — no hole opened

Un littéral interpolé a le kind string. Son AST est une concaténation des fragments, l'expression de chaque trou étant formatée par le formateur canonique de son kind (fmt.* — épinglé, identique sur chaque cible d'exécution), de sorte qu'une étiquette de mark ou d'alert peut être dynamique sans aucun code de formatage répétitif. Voir text pour les règles de formatage.

#Références de capacités (CAPREF)

CAPREF = IDENT ":" IDENT        (only inside a capability list)

Un descripteur du plan APP déclare ce qu'il peut toucher sous forme d'une liste de références de capacités — des paires namespace:verb comme chart:read, storage:own, levels:write, ou un simple IDENT pour les capacités à token unique (sfx) :

fluxapp structureGame {
  capabilities: [chart:read, storage:own, levels:write, sfx, app:launch]
  // …
}

CAPREF n'est délibérément pas une règle de lexer gloutonne. Il n'est reconnu que dans un seul état grammatical — élément d'une liste de capacités — de sorte que son : n'entre jamais en concurrence avec les autres deux-points du langage (champs de record f: v, propriétés at: (x, y), enfants when …:, le : du ternaire). Partout ailleurs, a:b est un identifiant, un deux-points et un identifiant avec leurs sens habituels.

À l'intérieur de ce seul état, le lexer lit le premier segment littéralement, même lorsqu'il épelle un mot réservé : app:launch est une référence de capacité licite bien qu'app soit un mot-clé dur partout ailleurs. Le relâchement est cantonné exactement à la position de namespace d'une liste de capacités ; il ne s'étend à aucune autre position du langage.

#Opérateurs et ponctuation

Trois faits lexicaux sont ici porteurs :

• Maximal munch dans la famille ? : le lexer essaie ??, puis ?., puis ?. Ainsi a??b est une coalescence, a?.b une navigation sûre, et a ? b : c un ternaire — aucune astuce d'espacement nécessaire, exactement comme .. l'emporte sur ..
• .. et -> sont des tokens uniques. Ni l'un ni l'autre n'est jamais deux caractères collés au moment de l'analyse, de sorte que bb.upper..bb.lower ne peut être mal lu (.. n'apparaît jamais dans la chaîne postfixe d'une expression) et aucune seconde écriture de flèche n'existe nulle part dans le langage.
• | n'a aucun rôle d'opérateur. Il n'apparaît qu'entre les constructeurs d'une déclaration variant (variant Phase { ask | suspense | revealed }). La disjonction booléenne est le mot or ; il n'y a pas d'opérateur ou-bit-à-bit (les opérations bit-à-bit sont les fonctions nommées de bits.*). Cela garde | sans collision avec chaque niveau d'expression.

Pourquoi un seul token flèche. Une syntaxe en flèche apparaît à cinq endroits (lambdas, câblage d'événements, paires de tween, bras de match, compréhensions), et les langages qui font croître des flèches écrites différemment pour ces rôles forcent les lecteurs à mémoriser quelle flèche va où. Flux décrète un seul symbole : -> est un token et une production grammaticale, et les cinq lectures sont sélectionnées par le contexte — la tête gardienne (on, match, for … in) ou, pour les usages non gardés, par l'inférence de kinds. La contribution du lexer à ce décret est minimale et stricte : il existe exactement une écriture de flèche. Le récit complet de la désambiguïsation est sur la page grammaire.

#Le modèle de mots-clés

Flux garde l'ensemble des mots-clés durs aussi petit que la grammaire le permet, en trois paliers plus un non-palier délibéré.

#Palier 0 — durs, réservés partout

Les lieurs, connecteurs, opérateurs et littéraux fondamentaux sont réservés à toute position :

def  let  in  if  then  else  for  match  with  variant  record  app
and  or  not  cross_up  cross_down  true  false  na

plus les deux connecteurs purement médians as et from. Ces mots ne peuvent jamais être un identifiant — ce sont des lieurs et des séparateurs dont la libération contextuelle n'apporterait rien et coûterait du lookahead. La seule exception cantonnée, décrite ci-dessus, est la position de namespace d'une référence de capacité, où app:launch lit app littéralement.

#Palier 1 — têtes contextuelles

Tout autre mot-clé du langage est contextuel : c'est un mot-clé à sa position de tête (le premier token de sa production, ou un connecteur médian comme over dans morph … over d) et un IDENT ordinaire dans les cinq emplacements de liaison :

Les mots de Palier 1, par famille :

• têtes d'instruction (ANALYSIS) : plot mark fill alert assert bars input
• têtes CANVAS et verbes d'événement : on group repeat spawn burst emit rate tween flash bounce pulse shake set when every hover click drag enter exit move wheel
• primitives CANVAS : dot circle ring rect square triangle poly line path text image svg sparkline backdrop column
• têtes et connecteurs TRANSITION : morph over focus replay scene
• têtes et hooks de representation : representation transform render reduce liveReduce updateLastUnit persistKey
• têtes et hooks d'outil de dessin : tool barExtent priceExtent
• têtes de membres du plan APP : capabilities init update subs contributes view
• outillage et modules : test import type
• connecteurs de clause réservés contextuellement à leur clause : at (dans assert … at), color (dans color bars:)

Les modificateurs de visibilité pub, private et package forment une sous-classe contextuelle distincte : ce ne sont pas des têtes de production mais des préfixes de déclaration, décidés par un token de lookahead (suivis d'une tête de déclaration ou d'une liaison, ce sont des modificateurs ; suivis de =, :, . ou (, ce sont de simples identifiants).

Un mot de Palier 1 n'est un mot-clé que là où le parser peut le décaler (shift) comme tel — à sa position de tête ou médiane. Partout ailleurs, le lexer restitue un identifiant ordinaire, donc def f(render) = render * 2 est licite, et la liaison render = 3 l'est aussi : le membre gauche d'une liaison décale un identifiant, pas une tête. Ce que vous ne pouvez pas faire, c'est utiliser le mot là où sa production l'attend en lui donnant un autre sens.

fluxrecord Stop { color: color }               // (a) field name + (d) kind name — both `color`
tool fib(a, b) {
  render: line { x1: a.bar; y1: a.price; x2: b.bar; y2: b.price }
}                                          // `render` is a keyword here — hook-head position
focus(view, over: 600ms)                   // (e) `over` as an argument label

Pourquoi la réservation contextuelle. Réserver purement et simplement chaque tête forcerait les auteurs à des noms distordus — focusRef, bounds, vdot — précisément là où focus, rect et dot sont le vocabulaire voulu du domaine. La réservation contextuelle conserve la lisibilité qu'apportent les instructions à tête de mot-clé (chaque instruction est engagée par son premier token) tout en rendant les mots aux auteurs dans les cinq emplacements où aucune tête ne peut jamais apparaître. Les deux côtés sont prouvablement disjoints : les emplacements de liaison siègent dans des états du parser où seul un IDENT est attendu, donc libérer un mot à cet endroit n'introduit d'ambiguïté nulle part — une affirmation que la construction de la grammaire revérifie mécaniquement à chaque changement.

#Réservé par anticipation

Flux réserve un mot avant de livrer sa production dès lors que le mot est destiné à la syntaxe de surface, afin qu'aucun programme existant ne puisse le masquer entre-temps (voir additivité). Les mots du plan APP (app, match, capabilities, init, update, subs, contributes, view, emit, variant) et les mots de module (import, pub, private, package) ont été réservés ainsi dès la première version et ont depuis reçu leurs productions.

Réservé. test en est l'instance actuelle : il est réservé en v1 sans production. Le bloc test "name" { … } est une commodité d'outillage dont la production sera livrée plus tard, de façon additive, avec ses tests de référence (golden tests).

#Délibérément NON réservés — les intégrés

Les noms de valeurs intégrées sont des identifiants ordinaires, pas des mots-clés :

close  open  high  low  volume  time  hl2  hlc3  ohlc4
bar  clock  screen  pane  ratio  depth  z  up  down  self  range

Un programme peut les lier — et un lint de style signale immédiatement le masquage :

fluxclose = 42            // legal — the shadowing lint flags: `close` hides the built-in series
plot close            // now plots 42 at every bar

Pourquoi ne pas les réserver. Ces noms sont du vocabulaire, pas de la structure. Réserver open, range ou z empoisonnerait d'immenses pans du nommage ordinaire (tout rectangle a un range, tout record un open quelconque), pour zéro bénéfice d'analyse — aucune production grammaticale n'y est ancrée. Un lint donne à l'auteur l'avertissement qui compte (le masquage accidentel d'une source de données) tout en gardant l'ensemble des mots-clés minimal, ce qui à son tour garde le récit de l'additivité propre : moins le langage possède de mots, moins il a de collisions futures à gérer.

#Erreurs lexicales

Parce que le lexer et le parser sont tous deux totaux, une entrée mal formée produit des diagnostics, jamais des crashs. Les rejets caractéristiques au niveau lexical :

fluxs = "unterminated          // ✗ syntax error — a string must close on its own line
x = 1.50 d                 // ✗ syntax error — juxtaposition (NUMBER then IDENT)
t =                     // ✗ syntax error — `se` does not complete a duration suffix

Tout le reste qui semble lexical — a < b < c, un -> égaré, un { a, b } en position d'expression — est rejeté une étape plus tard, par la grammaire ; ces diagnostics sont catalogués sur la page grammaire.

#Voir aussi

• Grammaire — la grammaire normative que ces tokens alimentent ; la flèche unique ; la précédence.
• Kinds — les kinds dimensionnels que portent les littéraux typés (DUR, PCT, SPAN, DEC…).
• Opérateurs — l'algèbre dimensionnelle derrière + - * / %, la famille ?, UFCS.
• Temps et état — ce que signifie le suffixe clock @ et pourquoi il est restreint.
• Text — le kind string, le formatage (fmt.*) et le pipeline d'interpolation.
• Prise en main — les mêmes tokens rencontrés dans l'ordre du programme.

Grammaire

Cette page est la syntaxe normative de Flux : chaque forme d'instruction, la grammaire complète des expressions, la flèche unique -> et ses cinq lectures contextuelles, l'échelle de précédence, les décisions de désambiguïsation qui gardent l'analyse déterministe, et les six propriétés formelles vérifiées par machine contre lesquelles la grammaire est figée. Les tokens (IDENT, NUMBER, STRING, TERM, …) sont définis dans structure lexicale ; ce que les programmes signifient est l'affaire des kinds, de l'inférence et du temps et état.

Il y a exactement une grammaire, et elle est énoncée une seule fois : l'EBNF normatif ci-dessous est exprimé comme une grammaire LR Lezer — le même artefact pilote le compilateur, l'éditeur et l'outillage de documentation, de sorte qu'il n'existe aucune seconde description de la syntaxe qui dériverait. Le fait que la construction de la grammaire soit acceptée avec zéro conflit non résolu est le contrôle machine que le langage est non ambigu (voir propriétés formelles).

Notation. { x } se répète zéro ou plusieurs fois, [ x ] est optionnel, | sépare les alternatives, "x" est un mot-clé littéral ou un token de ponctuation, et les noms en MAJUSCULES sont des tokens lexicaux issus du catalogue des tokens.

#Une grammaire, tous les plans

Les programmes Flux vivent sur quatre plans — ANALYSIS, CANVAS, TRANSITION et APP — mais la syntaxe est une grammaire unique. Le plan est inféré à partir des constructions utilisées, jamais annoté : il n'y a pas de pragma de plan, pas de commutateur de mode au niveau du fichier. plot et alert sont des sinks (puits) ANALYSIS ; on, les primitives de forme et spawn sont CANVAS ; morph, focus et replay sont TRANSITION ; un descripteur app est APP. Un seul fichier les mélange librement — un indicateur et sa présentation sont un seul programme — et le pare-feu entre plans (la présentation peut lire l'analyse, jamais l'inverse) est appliqué par l'analyse de dépendances sur l'arbre analysé, pas par la grammaire. Voir les quatre plans.

fluxplot close                                   // ANALYSIS — the smallest program
on click -> burst(40) dot { vel: 3 }         // CANVAS — same file, same grammar
morph chart over 600ms                       // TRANSITION

#Programmes et séparation des instructions

program  = { TERM } [ stmt { TERMSEP stmt } { TERM } ]
TERMSEP  = ( TERM | ";" ) { TERM | ";" }
sep      = ( TERM | "," | ";" ) { TERM | "," | ";" }

Un programme est une séquence d'instructions séparées par des sauts de ligne significatifs (TERM) et/ou des points-virgules optionnels ; les lignes vides sont libres. À l'intérieur des corps entre accolades, les éléments de liste sont séparés par sep — un saut de ligne, une virgule ou un point-virgule, indifféremment — ce qui explique qu'un record multi-ligne au niveau supérieur n'a pas besoin de virgules finales et qu'un bloc d'une ligne peut utiliser ;. Le saut de ligne ne compte comme séparateur qu'à la profondeur de parenthèses zéro : un corps entre accolades écrit à l'intérieur d'un appel est toujours dans les parenthèses de l'appel, donc ses éléments ont besoin d'un , ou ; explicite. La politique complète des sauts de ligne (quand un saut de ligne termine et quand il continue) est spécifiée dans structure lexicale.

Flux n'a pas d'instructions-expressions : une expression nue au niveau instruction est une erreur de syntaxe, ce qui est précisément ce qui rend les instructions terminées par saut de ligne non ambiguës.

fluxrsi(close, 14)        // ✗ syntax error — an expression is not a statement; write `plot rsi(close, 14)`

#Formes d'instruction

stmt = declStmt | plotStmt | markStmt | fillStmt | colorBarsStmt | alertStmt | assertStmt
     | onStmt | groupStmt | repeatStmt | forStmt | uiElement | primStmt | spawnStmt
     | tweenStmt | effectStmt | setStmt | morphStmt | focusStmt | replayStmt
     | appStmt | importStmt

Presque toute instruction est engagée par son premier token — l'idiome de tête-mot-clé : au niveau instruction, seul assertStmt peut commencer par assert, seul variantDecl par variant, et ainsi de suite. Le parser ne devine jamais ; chaque tête possède un état LR distinct. Les deux instructions qui commencent par un IDENT (une liaison, un conteneur de vue) et celle qui commence par { (une liaison déstructurante) sont résolues par un token de lookahead, catalogué ci-dessous.

#Déclarations

declStmt = [ visMod ] ( bindStmt | defStmt | typeDecl | variantDecl | recordDecl
                      | reprStmt | toolStmt )
visMod   = "pub" | "private" | "package"
bindStmt = letPat "=" expr
letPat   = recordPat | IDENT
defStmt  = [ DOC ] "def" IDENT "(" [ params ] ")" "=" expr
params   = param { "," param }
param    = IDENT [ "=" literal ]

Une liaison nomme une valeur pour le reste du programme ; son membre gauche est un identifiant unique ou un motif de record irréfutable qui déstructure sur place. Les liaisons sont immuables — il n'y a pas d'instruction d'affectation, et let n'existe qu'à l'intérieur des expressions.

fluxn = input(14, 2..200)
{upper, lower} = bollinger(close, 20)        // destructuring bind — no `:` after `{ IDENT`
let n = 20                                   // ✗ syntax error — `let` is expression-only; top-level binds are bare

Une définition de fonction lie un nom à une expression paramétrée. Les paramètres peuvent porter des valeurs par défaut littérales ; un doc-commentaire /// s'attache à la définition. La récursion est rejetée ([ErrTotalRec]) — la totalité par construction.

flux/// z-score of a series over n bars
def zscore(x, n=20) = (x - sma(x, n)) / stdev(x, n)
plot zscore(close) as z

Le modificateur de visibilité optionnel cantonne une déclaration pour le système de modules : pub traverse un import, package couvre les fichiers source d'un script, private (le défaut) reste dans son fichier. Le modificateur est contextuel — décidé par le token qui le suit — donc pub, private et package restent utilisables comme noms ordinaires dans les emplacements de liaison.

fluxpub def helper(x) = x * 2
private record Internal { a: num }
pub {upper, lower} = bollinger(close, 20)    // a modifier also prefixes a (destructuring) bind

#Types nommés — variant, record, alias

variantDecl = "variant" IDENT "{" { TERM } ctorDecl { "|" ctorDecl } { sep } "}"
ctorDecl    = IDENT [ "(" [ field { "," field } ] ")" ]
field       = [ IDENT ":" ] kindExpr
recordDecl  = "record" IDENT "{" { TERM } fieldDecl { sep fieldDecl } { sep } "}"
fieldDecl   = IDENT ":" kindExpr [ "=" ( literal | "na" ) ]
typeDecl    = "type" IDENT [ "(" IDENT { "," IDENT } ")" ] "=" kindExpr
kindExpr    = "vec" "(" kindExpr "," constLen ")"
            | "variant" "{" { TERM } ctorDecl { "|" ctorDecl } { sep } "}"
            | "record" "{" { TERM } fieldDecl { sep fieldDecl } { sep } "}"
            | IDENT [ "(" [ argList ] ")" ]
constLen    = NUMBER | IDENT

variant déclare un type somme nommé (constructeurs séparés par |, charges utiles positionnelles avec des noms de champs documentaires optionnels) ; record déclare un type produit nommé (chaque champ nommé et doté d'un kind, avec des valeurs par défaut constantes optionnelles) ; type déclare un alias transparent, possiblement paramétré — substitution, pas un nouveau type. Un kindExpr nomme un kind du treillis (price, osc(0,100)), un type déclaré, un vec(element, constLength), ou un variant{…} / record{…} structurel en ligne. Les chevrons ne sont jamais des délimiteurs de type — < et > sont exclusivement des opérateurs de comparaison — donc chaque forme paramétrée utilise des parenthèses.

fluxvariant Phase { ask | suspense | revealed }
variant Tool  { Select | Event(kind: num) | At(price) }   // named or anonymous payloads
record Level  { price: price; kind: num = 3; label: string }
record Inline {
  state: variant { Connecting | Ready }                   // inline structural kinds
  slots: vec(Level, 100)
}
type long = decimal(18, 0)
type Series(T) = vec(T, 500)                              // transparent, parameterized alias

Le graphe de références entre types nommés doit être acyclique — record Node { next: Node } est rejeté avec [ErrTotalType] à la résolution de noms, ce qui maintient chaque type fini.

#Sinks et paramètres ANALYSIS

plotStmt      = "plot" exprList [ "as" IDENT ] [ block ]
markStmt      = "mark" condExpr [ strLit ] [ block ]
fillStmt      = "fill" addExpr ".." addExpr [ block ]
colorBarsStmt = "color" "bars" ":" condExpr
alertStmt     = "alert" condExpr [ strLit ]
assertStmt    = "assert" condExpr [ strLit ] [ "at" addExpr ]
strLit        = STRING | interpStr
exprList      = expr { "," expr }

Les sinks (puits) publient les valeurs d'analyse vers l'hôte : plot trace des séries (optionnellement nommées avec as, optionnellement stylées avec un bloc final), mark dépose des marqueurs étiquetés sur une condition, fill ombre entre deux séries, color bars: colore les barres elles-mêmes, alert lève un message sur une condition, et assert énonce un invariant qui doit tenir à chaque barre — ou, avec at, sur une barre donnée. Une assertion dont la condition est na (échauffement) passe ; elle ne se déclenche que sur un signal assurément faux.

fluxbb     = bollinger(close, 20)
equity = cum(close - open)
fill bb.upper..bb.lower
color bars: if close > ema(close, 200)@"1d" then up else down
alert close cross_up open "crossed"
assert rsi(close, 14) <= 100 "rsi bounded"    // na on bars 0–13 — vacuously satisfied
assert equity > 0 "positive" at 500
mark rsi(close, 14) > 70 "overbought" { size: 8 }

Un paramètre de script est la forme d'expression input(…) (un primary, utilisable partout où une expression l'est) :

inputExpr    = "input" "(" inputDefault { "," inputArg } ")"
inputDefault = literal | IDENT | listLit
inputArg     = metaArg | inputExtra
metaArg      = IDENT ":" strLit
inputExtra   = addExpr [ ".." addExpr ]

La valeur par défaut doit être constante — un littéral, un identifiant de source, ou une liste d'étiquettes de chaîne (la forme énumérée) ; son kind fixe le kind du paramètre. Après la valeur par défaut viennent un range (2..200) ou une borne optionnels et des arguments méta-UI nommés (title:, group:, tooltip:, inline:), distingués d'un range par le lookahead IDENT : :

fluxlen  = input(14, 2..200)
src  = input(close)
name = input("fast", title: "Label", group: "Style")
mode = input(["ema", "sma"], tooltip: "kind")     // enumerated — a variant of the labels
dec  = input(1.50d)                                // decimal parameter

#Instructions CANVAS

onStmt      = "on" eventExpr ARROW action
eventExpr   = "hover" | "click" | "drag" | "enter" | "exit" | "move" | "wheel"
            | everyExpr | condExpr
everyExpr   = "every" "(" [ "~" ] ( DUR | SPAN | addExpr ) ")"
action      = stmt | block
groupStmt   = "group" [ block ]
repeatStmt  = "repeat" addExpr "as" IDENT [ block ]
forStmt     = "for" IDENT "in" condExpr ARROW uiChild
primStmt    = primitive [ "when" condExpr ]
primitive   = shapePrim [ block ] | contentPrim [ condExpr ] [ block ]
shapePrim   = "dot" | "circle" | "ring" | "rect" | "square" | "triangle" | "poly"
            | "line" | "path" | "backdrop" | "column"
contentPrim = "text" | "image" | "svg" | "sparkline"
spawnStmt   = ( "spawn" | "burst" "(" addExpr ")" | "emit" "rate" "(" addExpr ")" ) primitive
tweenStmt   = "tween" propPath arrowPair [ overClause ]
setStmt     = "set" propPath "=" expr
effectStmt  = ( "flash" | "bounce" | "pulse" | "shake" ) [ postfix ] [ block ]
propPath    = IDENT { "." IDENT }

on câble un événement — un verbe d'interaction, une cadence every(…), ou n'importe quel flux booléen — à une action. Une primitive dessine un élément, avec un bloc de propriétés et un garde when final optionnel. spawn / burst(n) / emit rate(r) créent des éléments éphémères issus d'un pool ; tween, set et les mots d'effet animent des propriétés. La sémantique de tout cela vit sur la page CANVAS ; grammaticalement, ce sont des instructions à tête de mot-clé partageant l'unique forme block.

fluxon click -> group { dot { at:(bar.i, close); r: 4 } }
on every(1 bars) -> spawn ring { r: 6->24; life: 200 bars }
on every(~ 500ms) -> pulse                       // `~` — approximate cadence
on close > highest(close, 250)[1] -> burst(40) dot { vel: 3 }
emit rate(norm(volume) * 40) dot { size: 2 }
tween p.r 6->24 over 300ms
circle { at:(spring(close)); trail: 24 } when close > open

Conteneurs de vue et compréhension. Un conteneur de vue est une tête d'identifiant (optionnellement appelée) suivie d'un corps entre accolades obligatoire d'enfants ; la compréhension for … in … -> est une forme instruction/enfant uniquement — for ne commence jamais une expression (le mappage pur de données est vec.map) :

uiElement = IDENT [ callTail ] uiBlock
uiBlock   = "{" { TERM } [ uiChild { sep uiChild } { sep } ] "}"
uiChild   = uiElement | forStmt | whenChild | primStmt | expr
whenChild = "when" condExpr ":" uiChild

fluxslots = window(close, 5)
row { text "a"; text "b" }
panel(slot: side) { col { for s in slots -> renderSlot(s) } }
grid(cols: 2) { when close > open: text "up"; col { text "deep" } }

Un conteneur sans enfant (button(reset), panel(slot: x)) n'est pas un uiElement — c'est une expression d'appel ordinaire de kind ui ; c'est le corps entre accolades qui fait la forme conteneur.

#Instructions TRANSITION

morphStmt  = "morph" ( "chart" | IDENT ) [ overClause ] [ block ]
overClause = "over" condExpr
focusStmt  = "focus" "(" "view" { "," arg } ")"
replayStmt = "replay" "from" condExpr overClause

fluxanchors = window(close, 10)
morph chart over 600ms
morph pnf { keep: anchors }
focus(view, over: 600ms, pad: 5%)     // `over` here is an argument label, not the clause keyword
replay from close > 100 over 2s

#Representations et outils de dessin

reprStmt  = "representation" IDENT "(" [ params ] ")" reprBlock
reprBlock = "{" { TERM } [ reprHook { sep reprHook } { sep } ] "}"
reprHook  = reprKey ":" reprVal
reprKey   = "transform" | "render" | "reduce" | "liveReduce" | "updateLastUnit" | "persistKey"
reprVal   = primStmt | block | expr
toolStmt  = "tool" IDENT "(" [ params ] ")" toolBlock
toolBlock = "{" { TERM } [ toolHook { sep toolHook } { sep } ] "}"
toolHook  = toolKey ":" toolVal
toolKey   = "barExtent" | "priceExtent" | "render"
toolVal   = primStmt | block | expr

Les deux sont des formes de déclaration à tête de mot-clé dont les corps sont une énumération fermée de hooks — le script écrit les fonctions pures (géométrie, rendu, réduction), l'hôte fournit tout le reste (placement, hit-testing, persistance ; d'où hitTest et lod ne sont pas des mots-clés et restent des noms libres). Voir intégration hôte.

fluxrepresentation pnf(box, rev) {
  transform: rebin(close, box, rev)
  render: column { w: 1 }
  reduce: decimate(cols, k)
  liveReduce: mutateHead(cols)
  updateLastUnit: patch(cols)
  persistKey: "pnf-v1"
}

tool fib(a, b) {
  barExtent: (a.bar, b.bar)
  priceExtent: (a.price, b.price)
  render: line { x1: a.bar; y1: a.price; x2: b.bar; y2: b.price }
}

#Le descripteur APP

appStmt    = "app" IDENT appBody
appBody    = "{" { TERM } [ appMember { sep appMember } { sep } ] "}"
appMember  = capEntry | memberDef
capEntry   = "capabilities" ":" capList
capList    = "[" { TERM } [ capRef { "," capRef } { sep } ] "]"
capRef     = CAPREF | IDENT
memberDef  = ( "init" | "update" | "view" | "subs" | "contributes" )
             "(" [ params ] ")" "=" memberBody
memberBody = uiElement | expr

Une app est un descripteur nommé avec une entrée capabilities: et les cinq membres fixes du harnais TEA (TEA — The Elm Architecture). Les têtes de membres sont des mots-clés, pas des identifiants — la forme est délibérément sans def parce que ces cinq rôles sont fixes. memberBody est le seul endroit de la grammaire où un conteneur de vue au niveau instruction est le membre droit de = (un view renvoie une vue) ; partout ailleurs, le membre droit de = est une expression.

fluxapp structureGame {
  capabilities: [chart:read, storage:own, levels:write, sfx]
  init(p) = {score: 0, phase: ask}
  update(m, msg) = match msg {
    Tick(dt) -> m with {score: m.score + dt}
    _ -> m
  }
  view(m) = panel(slot: side) {
    row { text "score {m.score}"; when m.done: button(reset) }
    for t in TOOLS -> button(t)
  }
  subs(m) = [OnTick(Tick)]
}

La sémantique du plan APP — Model, Msg, commandes en tant que données inertes, souscriptions — est spécifiée sur la page du plan APP.

#Imports et visibilité

importStmt = "import" pkgRef [ "as" IDENT ]
pkgRef     = IDENT "/" IDENT

import author/package lie un paquet sous son nom ou un alias as ; seules les déclarations pub du paquet sont atteignables, en tant que noms qualifiés mod.f. Le / de la coordonnée n'est jamais confondu avec une division — il n'est atteignable qu'après import IDENT, un état où aucune expression n'existe.

fluximport acme/wyckoff as wk
pub def helper(x) = wk.zone(x) * 2

Post-v1. Le mécanisme d'import, la résolution adressée par contenu et la sémantique du lockfile sont entièrement spécifiés (paquets) ; le déploiement du registre public est différé.

#Expressions

La grammaire des expressions est une stratification stricte : chaque niveau ne se réfère qu'au niveau immédiatement plus serré, de sorte que la précédence est intégrée dans la forme même de la grammaire (aucune déclaration de précédence n'est nécessaire pour la chaîne arithmétique, et l'analyse est LR(1) par construction).

expr      = arrowExpr
arrowExpr = condExpr [ ARROW expr ]                (right-assoc; lambda or pair — see below)
condExpr  = ifExpr | letExpr | ternExpr
ifExpr    = "if" expr "then" expr "else" expr      (else mandatory)
letExpr   = "let" letPat "=" expr "in" expr
ternExpr  = coalExpr [ "?" expr ":" expr ]         (≡ if/then/else)
coalExpr  = orExpr [ "??" coalExpr ]               (right-assoc; ≡ nz)
orExpr    = andExpr { "or" andExpr }
andExpr   = notExpr { "and" notExpr }
notExpr   = "not" notExpr | cmpExpr
cmpExpr   = addExpr [ cmpOp addExpr ]              (NON-associative)
addExpr   = mulExpr { addOp mulExpr }
mulExpr   = unary { mulOp unary }
unary     = "-" unary | postfix
postfix   = primary { callTail | indexTail | clockTail | memberTail | safeNavTail | withTail }
primary   = NUMBER | DEC | DUR | PCT | PX | SPAN | RATE | STRING | interpStr | BOOL | "na"
          | IDENT | inputExpr | tweenSig | matchExpr | listLit | recordLit | blockExpr
          | sceneExpr | parenForm
tweenSig  = "tween" "(" arrowPair [ "," argList ] ")"
arrowPair = condExpr ARROW condExpr

#Conditionnelles : if, let, ternaire, coalescence

if porte toujours un else — il n'y a pas de problème de dangling-else car la forme incomplète n'existe pas. let … in cantonne une liaison (ou une déstructuration irréfutable) sur une expression de corps. Le ternaire est le même arbre que if/then/else, et ?? est du sucre pour nz (remplacer na par une valeur par défaut) :

fluxplot if close > open then 1 else 0
r = let x = close - open in x * x
d = let { upper, lower } = bollinger(close, 20) in upper - lower   // destructuring let
t = close > open ? 1 : 0                     // ≡ if close > open then 1 else 0
z = close[1] ?? 0                            // ≡ nz(close[1], 0)
x = if a then 1                              // ✗ syntax error — else is mandatory

#match

matchExpr = "match" condExpr "{" { TERM } matchArm { sep matchArm } { sep } "}"
matchArm  = pattern ARROW expr
pattern   = "_" | "na" | ctorPat | recordPat | IDENT
ctorPat   = IDENT [ "(" [ IDENT { "," IDENT } ] ")" ]
recordPat = "{" [ IDENT { "," IDENT } ] "}"

match est l'éliminateur des valeurs variant (et de na), utilisable dans toute position d'expression. Le sujet du match (scrutinee) est sans flèche (condExpr), de sorte que chaque -> à l'intérieur des accolades appartient à un bras. Les motifs sont plats en v1 : joker, na, un constructeur avec des noms de charge utile liés, une déstructuration de record, ou un identifiant de liaison — pas d'imbrication profonde. L'exhaustivité est vérifiée statiquement ; un match non exhaustif est rejeté avec [ErrTotalMatch].

fluxvariant Phase { ask | suspense | revealed }
variant Tool  { Select | Event(kind: num) | At(price) }
m = { phase: ask }
t = Event(3)
next = match m.phase {
  ask -> suspense
  suspense -> revealed
  _ -> ask
}
which = match t { Event(k) -> k; At(p) -> 0; _ -> na }
q = SaveState.Saved            // a qualified constructor disambiguates cross-variant homonyms

Une étiquette nullaire et un identifiant de liaison sont le même arbre d'analyse (un motif IDENT) ; savoir si ask nomme un constructeur connu ou lie une variable fraîche est résolu sémantiquement, exactement comme la résolution de fonction — jamais une bifurcation d'analyse.

#Littéraux de record, de liste et de bloc ; scene

recordLit = "{" { TERM } fieldAssign { sep fieldAssign } { sep } "}"     (≥ 1 field)
fieldAssign = IDENT ":" expr
listLit   = "[" { TERM } [ expr { "," expr } { sep } ] "]"
blockExpr = "{" { TERM } { blockBind sep } expr { TERM } "}"
blockBind = IDENT "=" expr
sceneExpr = "scene" uiBlock
parenForm = "(" [ parenItem { "," parenItem } ] ")"
parenItem = expr [ ".." expr ]

Un littéral de record construit le premier record ({a: 1, b: 2} ; un {} vide n'est pas un record). Un littéral de liste construit un vec borné ([1, 2, 3], [] — la colonne vertébrale de toute liste de commandes APP). Une expression de bloc séquence des liaisons immuables avant une expression finale et se désucre en let … in imbriqués — la forme de corps multi-ligne :

fluxm = {a: 1, b: 2}
xs = [1, 2, 3]
empty = []
v = { x = 1; y = x * 2; y + x }      // blockExpr — desugars to let x = 1 in let y = … in y + x
w = { close }                        // a one-expression block
bad = { a, b }                       // ✗ syntax error — neither a record (no `:`) nor a block (no `=`)

scene { … } empaquette une scène CANVAS multi-éléments comme une valeur de kind ui — la seule forme d'expression d'une scène, qui vit sinon au niveau instruction. C'est ainsi qu'un def renvoie un overlay :

fluxdef overlayOf(d) = scene {
  line { a: d.a; b: d.b }
  for it in items(d) -> dot { at:(it.bar, it.price) }
}

La forme parenthésée unifie le groupement, les coordonnées et les têtes de lambda : (x) groupement, (x, y) une paire coordonnée/argument (at:(bar.i, close)), (2..200) un opérande de range, (p) -> … une tête de lambda.

#La chaîne postfixe

callTail    = "(" [ argList ] ")"
indexTail   = "[" expr "]"
memberTail  = "." IDENT
safeNavTail = "?." IDENT
clockTail   = "@" clockOperand
clockOperand = STRING | IDENT [ callTail ] | "(" expr ")"
withTail    = "with" recordUpdateBody
recordUpdateBody = "{" { TERM } [ fieldAssign { sep fieldAssign } { sep } ] "}"
argList     = arg { "," arg }
arg         = [ IDENT ":" ] expr
arrowPair   = condExpr ARROW condExpr

Les six suffixes lient au même niveau (le plus serré) et s'associent à gauche, dans l'ordre lexical :

fluxslots = window(close, 20)
bb    = bollinger(close, 20)
m     = { a: 1 }
i     = input(0, 0..19)
chain = bollinger(close, 20).upper[1]@"1d"
//      ((( bollinger(close,20) ).upper )[1] )@"1d"
prev  = close[1]                       // [Delay] — scalar stream, constant index
s     = slots[i]                       // [Index] — vec element, runtime index, out-of-bounds → na
htf   = ema(close, 50)@"1d"            // clock suffix — see time-and-state
safe  = bb?.upper                      // na-propagating navigation
y     = m with {a: 3}                  // functional record update — shape-preserving

L'opérande de @ est délibérément restreint (une chaîne, un identifiant ou un appel, ou une expression parenthésée) de sorte que x@"1d" + 1 s'analyse comme (x@"1d") + 1 sans subtilités de précédence. with { … } est un mot-clé postfixe, pas une expression menée par une accolade — le corps de mise à jour n'est atteignable qu'après le mot with, ce qui le maintient distinct de toute autre accolade.

Les arguments peuvent être étiquetés (focus(view, over: 600ms)) ; l'étiquette est décidée par le lookahead IDENT :. L'accès membre fait aussi office d'UFCS — close.ema(20).rsi(14) est rsi(ema(close, 20), 14) ; le . se résout en champ, appel de fonction ou nom de module qualifié à la compilation sans impact sur la grammaire (voir Opérateurs).

#Lambdas

Un lambda est une flèche dont le côté gauche est une forme parenthésée d'identifiants nus, dans une position qui attend une fonction (les arguments d'ordre supérieur de fold, map, scan, loop, …) :

fluxdef ema0(s, n) = let a = 2/(n+1) in scan(s, (p) -> a*s + (1-a)*p)

r   = window(close / close[1], 20)   // a vector of ratios
sq  = vec.map(r, (x) -> x * x)
inc = vec.map(r, _ + 1)              // placeholder sugar — exactly one `_`, mono-argument

Les parenthèses font partie de la forme — un x -> … nu en position de valeur est une paire de tween, pas un lambda (voir la section suivante) ; le raccourci à argument unique est le placeholder _. Un corps multi-instructions est une expression de bloc : (x) -> { d = x - open; d * d }.

#Blocs et propriétés

block     = "{" { TERM } [ item { sep item } { sep } ] "}"
item      = propEntry | stmt
propEntry = IDENT [ ":" propValue ]
propValue = arrowPair | addExpr ".." addExpr | condExpr
literal   = NUMBER | DEC | DUR | PCT | PX | SPAN | STRING | BOOL

Il y a une seule forme de bloc. Ses éléments sont des propriétés (key: value, ou un simple drapeau comme stagger) et/ou des instructions ; laquelle des deux une tête donnée permet (un bloc dot prend des propriétés, un bloc group prend des instructions) est une restriction sémantique, pas une grammaire séparée. Une valeur de propriété peut être une valeur simple, un range lo..hi, ou une paire de tween a->b :

fluxdot { at:(bar.i, close); r: 6->24; glow: 16; span: 2..8; stagger }

#La flèche unique

-> est un token et une production grammaticale — Arrow { lhs, rhs } — avec cinq lectures sélectionnées entièrement par le contexte. Il n'y a pas de second symbole flèche nulle part dans le langage.

Déterministe par construction, en deux étapes :

• Les flèches gardées n'atteignent jamais la grammaire des expressions. Dans on EVENT -> ACTION, match e { pattern -> expr } et for x in coll -> child, l'opérande avant la flèche est un condExpr — une strate qui exclut arrowExpr — de sorte que l'événement, le sujet et la collection ne peuvent jamais absorber le ->. La flèche est revendiquée par la production propre de la tête, sans aucun choix pour le parser.
• Les flèches non gardées construisent un seul arbre ; le rôle est décidé à l'inférence. a -> b dans une expression s'analyse comme l'unique nœud Arrow, qu'elle agisse comme un lambda ou comme une paire de tween. L'inférence de kinds la lit comme un lambda exactement quand le côté gauche est une forme parenthésée d'identifiants nus et que la position attend une fonction ; sinon c'est une paire de valeurs (6->24). Le même arbre sert aussi la production de paire dédiée arrowPair utilisée par tween et les valeurs de propriété.

fluxplot -> 3            // ✗ syntax error — an arrow needs a left side; no production begins with ->

Pourquoi une seule flèche. Cinq flèches écrites différemment exigeraient cinq tokens, cinq entrées de précédence et une table mentale du lecteur associant écriture et rôle. Un seul token avec des lectures gardées par la tête ne coûte rien à la grammaire (chaque garde est un état LR que la tête possède déjà), garde chaque programme visuellement cohérent, et déplace la seule véritable ambiguïté — lambda versus paire — vers le vérificateur de kinds, qui doit de toute façon inspecter cette position. Le parser ne bifurque jamais.

#Précédence et associativité

Du plus lâche au plus serré ; chaque niveau est une strate de la grammaire ci-dessus :

Conséquences qui méritent d'être explicitées :

fluxm = -close[1] * 2                 // (-(close[1])) * 2 — unary minus tighter than `*`, postfix tighter still
p = close > open                  // signal
q = volume > sma(volume, 20)      // signal
r = not p and q or p              // ((not p) and q) or p
s = m ?? 0.0                      // m ?? 0.0 — null-coalescing
t = close > open ? high : low     // (close > open) ? high : low
e = macd(close).hist[1]@"1d"    // (((macd(close)).hist)[1])@"1d" — postfix chain, lexical order
bad = a < b < c              // ✗ syntax error — comparisons do not chain (non-associative)

Hors de l'échelle. Trois familles de tokens ne prennent aucun niveau de précédence. Le range .. est non associatif et n'apparaît que dans ses emplacements dédiés (fills, spans, ranges d'input, éléments de parenthèse, valeurs de propriété) — jamais à l'intérieur de la cascade d'opérateurs, de sorte que bb.upper..bb.lower n'a besoin d'aucune parenthèse. Le suffixe clock @ restreint son opérande droit à un clockOperand, de sorte que x@"1d" + 1 est (x@"1d") + 1 par construction. Et : et , sont de purs séparateurs.

Pourquoi la stratification plutôt que des annotations de précédence. Chaque strate ne se réfère qu'à la suivante, plus serrée — il n'y a de récursion croisée nulle part dans la grammaire des expressions — de sorte que l'automate LR est la table de précédence. Rien n'a besoin d'être déclaré, donc rien ne peut être déclaré de façon incohérente ; le niveau de comparaison non associatif est une production qui ne se répète pas. L'interdiction de chaîner les comparaisons existe parce que a < b < c n'a aucune lecture booléenne dans un langage dimensionnel (la première comparaison produit un signal, qui n'est pas ordonné par rapport à c — la grammaire rejette la forme avant que le vérificateur de kinds ne le fasse).

Sauts de ligne. Le séparateur d'instruction TERM et ses règles de continuation interagissent avec cette échelle (un opérateur infixe en début de ligne continue la ligne précédente). La politique est lexicale et spécifiée dans structure lexicale.

#Catalogue de désambiguïsation

Chaque endroit où deux constructions pourraient se disputer le même token est fermé par l'un de cinq dispositifs : une règle de tokeniseur, la stratification, un mot-clé de tête gardien, des états LR distincts, ou un token de lookahead borné. Le plan de conception énumère chaque conflit potentiel et sa résolution ; la construction de la grammaire re-prouve mécaniquement l'absence de conflits à chaque changement. Les cas qu'un lecteur rencontre réellement :

L'accolade. Toutes les lectures de { sont séparées par l'endroit où l'accolade est atteinte :

Deux formes menées par une accolade — et seulement deux — peuvent commencer une expression (littéral de record, expression de bloc), et un token après { IDENT les sépare ; un { a, b } nu en position d'expression n'est ni l'un ni l'autre, et est rejeté. Toute autre accolade est atteinte après un token gardien, dans un état LR où aucune expression ne peut commencer — de sorte que le parser ne bifurque jamais sur {.

Le crochet. [ au début d'une expression ouvre un littéral de liste ; [ collé après un postfixe est un index. Les deux siègent dans des états d'automate différents (attente-d'une-valeur versus détention-d'une-valeur), de sorte qu'aucune entrée n'atteint les deux. L'unique forme d'index porte alors deux rôles de typage, choisis par le kind du récepteur, pas par la grammaire : sur un flux scalaire avec un index constant, c'est le delay causal close[1] ; sur un vec, c'est l'accès à un élément slots[i] (index d'exécution, hors bornes produit na).

Éléments après un identifiant. À l'intérieur d'un bloc, le token après un IDENT en tête aiguille : : → propriété, = → liaison, { → conteneur de vue, ( → appel (puis un { qui suit en fait un conteneur ; sinon il reste un appel — le même arbre Call dans les deux cas, la question du conteneur est sémantique), séparateur/} → simple drapeau ou enfant expression.

when, deux fois. when c: child (un enfant de vue conditionnel, avec :) versus dot { … } when c (un garde final sur une primitive, sans :) — le deux-points décide.

at contextuel. Dans assert cond "msg" at 500, at n'est un mot-clé que dans cette position de clause (après la condition et le message optionnel). Il n'entre jamais en collision avec la clé de propriété at: d'un bloc canvas, qui est un IDENT : au niveau élément.

Le deux-points de capacité. chart:read est un token CAPREF unique reconnu uniquement à l'intérieur d'une liste de capacités ; le [ de capabilities: [ … ] n'est de même atteint qu'après capabilities :, jamais en position d'expression. Aucun autre deux-points du langage ne peut apparaître dans cet état (détails).

color contextuel. color n'est un mot-clé qu'en tête de la séquence à deux tokens color bars ; suivi de n'importe quoi d'autre, c'est un identifiant ordinaire — ce qui permet à color de nommer à la fois un champ et le kind color (record Stop { color: color }).

La famille ?. Le maximal munch du lexer ordonne ?? > ?. > ? ; les productions siègent ensuite à trois strates différentes (coalescence, postfixe, ternaire). Le : du ternaire n'est atteignable qu'après ? expr, un état LR disjoint de tout autre deux-points.

Préfixes de visibilité. pub / private / package sont des modificateurs exactement quand ils sont suivis d'une tête de déclaration ou d'une liaison ; suivis de =, :, . ou (, ce sont de simples identifiants. Comme deux identifiants adjacents ne sont jamais une analyse valide, pub def … s'engage de façon déterministe.

#Propriétés formelles

La grammaire est figée contre six critères, chacun avec une vérification par machine — concevoir en éliminant les mauvais états, puis vérifier par machine, plutôt que d'être prudent :

Trois de ces vérifications méritent une phrase chacune :

• La construction est la preuve de non-ambiguïté. La grammaire normative est exprimée une seule fois, comme une grammaire LR Lezer ; un générateur LR rapporte chaque conflit au moment de la construction, de sorte que « la construction est verte » est un contrôle machine de non-ambiguïté — pas une affirmation de revue. (Un formalisme à choix ordonné a été rejeté pour exactement cette raison : il ne détecte pas l'ambiguïté, il la cache silencieusement.) Le même artefact pilote le compilateur, les services de syntaxe de l'éditeur et l'outillage de documentation, de sorte qu'il n'y a rien qui puisse dériver.
• Le corpus fait l'aller-retour. Chaque exemple du corpus est analysé, imprimé par le formateur canonique, et ré-analysé ; les deux arbres doivent être identiques. Un bug de grammaire et un bug de formateur cassent la même barrière. (Le corpus est aussi la suite golden, de sorte qu'un exemple ne peut pas pourrir sans qu'un test passe au rouge.)
• Le parser est total. Le fuzzing assère que toute séquence d'octets soit s'analyse en un arbre unique, soit est rejetée avec des diagnostics propres — jamais un crash, jamais un blocage. L'entrée mal formée fait partie du domaine du langage.

La cohérence sémantique s'étend au-delà de l'analyse : pour chaque kind, l'admissibilité de chaque opérateur, comparaison, fill et plot est énumérée sur l'ensemble des kinds fini par famille, de sorte qu'aucune paire kind/construction n'est laissée sans un sens ou une erreur nommée. Le harnais de vérification est décrit dans compilateur et runtime et les garanties elles-mêmes dans garanties.

#Additivité et versionnage

La grammaire évolue sous une politique d'additivité stricte :

• Un script valide reste valide indéfiniment. La sémantique d'une construction existante n'est jamais altérée ; la surface ne fait que croître. Chaque extension doit elle-même prouver zéro conflit à la construction de la grammaire avant d'atterrir — l'additivité est une barrière de construction, pas une promesse.
• Les versions de langage sont déclarées, optionnellement. Chaque fichier source peut porter un marqueur de version de langage ; un fichier sans marqueur signifie « courant ». (Le schéma de données d'une app — son variant Msg et son modèle — est versionné séparément par l'app elle-même ; voir le plan APP.)
• Les mots-clés sont réservés par anticipation. Les mots destinés à une future syntaxe de surface sont réservés avant que leurs productions ne soient livrées, de sorte qu'aucun programme écrit aujourd'hui ne peut masquer la syntaxe de demain — test est l'exemple permanent (modèle de mots-clés). Combiné à la réservation contextuelle, cela rend la croissance future sans collision par construction.
• La promesse du codemod. Si une dépréciation devenait un jour inévitable, un codemod automatique réécrirait les sources affectées au chargement — mécaniquement, pas en demandant aux auteurs de migrer à la main. Rien en v1 n'est déprécié.

Pourquoi cette règle existe. Un langage total et déterministe est une promesse sur le futur d'un programme, pas seulement sur son présent : un script qui rejoue de façon byte-identique aujourd'hui doit encore s'analyser — et signifier la même chose — sous chaque compilateur ultérieur. L'additivité stricte est la moitié syntaxique de cette promesse ; les invariants de routine épinglée et de byte-identité en sont la moitié sémantique (compilateur et runtime).

#Voir aussi

• Structure lexicale — les tokens, le saut de ligne significatif, les paliers de mots-clés.
• Kinds — le treillis dimensionnel contre lequel l'arbre analysé est vérifié.
• Opérateurs — l'algèbre dimensionnelle par opérateur, UFCS, with, la famille ?.
• Inférence — comment les kinds (et la flèche lambda-versus-paire) sont décidés sur l'arbre.
• Le plan CANVAS · Le plan APP — sémantique des familles d'instructions ci-dessus.
• Garanties — la page de confiance : chaque propriété vérifiée par machine en un seul endroit.

Kinds — le système de types dimensionnels

Chaque valeur en Flux porte un kind : un énoncé de ce que la valeur signifie, pas simplement de la façon dont elle est stockée. close n'est pas « un float » — c'est un price, un point sur l'axe des prix. close − open n'est pas « un autre float » — c'est un level, un déplacement le long de cet axe. rsi(close, 14) est un oscillateur borné, osc(0,100). Parce que le sens est suivi, le compilateur rejette l'arithmétique dénuée de sens à la compilation, réconcilie sainement les branches et les séries co-tracées, et infère la présentation — pane, échelle, guides — à partir du seul kind. Les kinds sont la clé de voûte du langage : la causalité, la totalité, l'inférence de présentation et les garanties de l'optimiseur reposent toutes sur eux.

Le mécanisme est général. La même machinerie donne un kind à l'arithmétique calendaire, aux montants décimaux exacts, aux unités physiques (meas[u]), aux records et variants déclarés par l'utilisateur, et aux messages et vues du plan APP ; les kinds de données de marché sont l'instanciation phare et servent d'illustrations fil rouge ici. Ce chapitre est la référence normative pour le système de kinds lui-même — ses deux systèmes coopérants, ses sortes et son ordre partiel, la borne supérieure et la borne inférieure, ses tags orthogonaux, et les déclarations nommées. Les règles par opérateur vivent dans Opérateurs ; l'algorithme d'inférence, la politique d'erreurs complète, et la table complète kind → présentation vivent dans Inférence.

#Deux systèmes, un seul canal d'erreur

« Borne supérieure et borne inférieure des opérations binaires » est une erreur de catégorie, et le système de kinds est bâti sur son refus. price − price = level, pourtant price ⊔ price = price — la soustraction et l'unification répondent à des questions différentes. Flux sépare donc proprement deux systèmes :

• (A) Le treillis de coercition (K, ≤, ⊔, ⊓, ⊤, ⊥). a ≤ b signifie « a se coerce en b sans mentir sur lui-même ». La borne supérieure ⊔ unifie — les branches d'un if, les deux arguments de nz, les séries co-tracées dans un même pane. La borne inférieure ⊓ contraint — le kind qu'un paramètre exige, l'intersection des bornes d'oscillateur. Le treillis répond à « existe-t-il un kind qui couvre les deux ? » — rien de plus.
• (B) L'algèbre dimensionnelle des opérateurs pour + − × ÷ < > == — une table de règles qui calcule le kind résultat de chaque opération à partir des kinds de ses opérandes, dans le style de l'analyse dimensionnelle classique. Ce n'est pas la borne supérieure : elle peut se déplacer à travers le treillis (price − price → level) ou refuser catégoriquement (price + osc → ⊤).
• Un seul canal d'erreur : ⊤. Chaque règle non définie dans (B) et chaque incompatibilité dans (A) produit le même élément sommet ⊤. Un ⊤ est une erreur dure dans une position exigeante — un opérande, une cible de plot, un argument — et un opérande est lui-même une position exigeante, c'est pourquoi close + rsi(…) échoue au +, que quoi que ce soit en aval le lise ou non. Un ⊤ qui n'atteint aucune position exigeante est un avertissement ([WarnTop]), pas un échec.

Lisez les deux règles ci-dessus ensemble et il en découle une chose facile à manquer, et qui mérite d'être dite franchement, car c'est la différence entre un système de types strict et un système simplement bruyant : un mélange de dimensions n'atteint jamais ⊤. Ajoutez un price à un oscillateur et l'algèbre n'a aucune règle, vous obtenez donc ⊤ et un [ErrDim] dur. Mais réconciliez un price et un oscillateur — prenez l'une ou l'autre branche d'un if — et la borne supérieure n'échoue pas. Elle efface la dimension et atterrit sur quantity : un kind réel, un nombre qui se souvient qu'il est un nombre et a oublié de quoi. C'est un [WarnBranchDim], et la valeur s'écoule.

Le canal dur est pour le non-sens qui est certain ; le canal doux pour un mélange qui n'est que suspect. Ce qui les sépare n'est pas la consommation — c'est l'endroit où le ⊤ est né. ⊤ apparaît quand même dans une réconciliation, et y est quand même dur : un if dont les branches traversent des sortes (un price et une couleur) n'a aucun kind commun du tout, et aucun effacement ne peut le sauver.

Pourquoi cette règle existe. Si − était modélisée comme une borne supérieure, close − open aurait le kind price ⊔ price = price — un déplacement mal étiqueté comme un point, et chaque règle en aval (price + level → price, placement d'overlay, choix d'axe) partirait silencieusement de travers. Si les borne supérieures étaient modélisées comme de l'algèbre, if c then ema12 else ema26 aurait besoin d'une « règle d'opérateur » pour une question qui est en réalité « ces deux branches partagent-elles un kind ? ». Garder les deux systèmes séparés — et les laisser échouer dans un unique ⊤ partagé — réconcilie un treillis total (chaque paire de kinds a une borne supérieure) avec un système qui rejette encore le non-sens (cette borne supérieure est ⊤ exactement là où aucun kind commun honnête n'existe).

fluxfast   = volume > sma(volume, 20)

spread = close - open              // price − price → level   (algebra, system B)
line   = if fast then ema(close, 12) else ema(close, 26)
                                   // price ⊔ price → price   (join, system A)
plot spread, line

// ✗ plot close + rsi(close, 14)   — [ErrDim]: point + dimensionless has no affine meaning

Trois échecs, et ce ne sont pas le même échec :

fluxfast = volume > sma(volume, 20)

mix  = if fast then close else rsi(close, 14)   // ⚠ [WarnBranchDim] — no common dimension, so
plot mix                                        //   the join ERASES it: mix : quantity. It flows.

// ✗ plot close + rsi(close, 14)   — [ErrDim]: the ALGEBRA has no rule for point + dimensionless.
//                                   Hard, at the `+`, read or not: an operand is a demanding
//                                   position, and there is nothing suspicious about this — a
//                                   point plus a bare number is not a thing.
// ✗ if fast then close else up    — [ErrDim]: price ⊔ color = ⊤. Crossing SORTS is not a mixture
//                                   the lattice can erase — there is no common kind to land on.

[WarnTop] est le lint qui se pose au sommet du premier cas : une liaison dont la dimension a été effacée et que personne ne lit est presque toujours une erreur en devenir, donc laissez mix non tracé et vous obtenez un second avertissement disant exactement cela. Consommez-la et le [WarnTop] disparaît — le [WarnBranchDim] reste, car l'effacement est toujours là.

Un ⊤ se propage aussi comme un poison de kind sans re-diagnostiquer : une seule faute racine produit un seul message, et chaque nœud qu'il contamine reste silencieux (la règle anti-cascade ; voir Inférence pour le cône typable qui maintient l'aperçu en direct fonctionnel autour de lui).

#Le substrat affine

L'asymétrie de l'algèbre n'est pas une convention — c'est de la géométrie. L'axe des prix est un espace affine à une dimension :

• price est un point sur cet axe,
• level est un vecteur — un déplacement entre points,
• ratio est un scalaire sans dimension.

La géométrie affine livre alors gratuitement les règles fondamentales : point − point = vecteur (price − price → level), point ± vecteur = point (close + atr(14) → price), point ÷ point = scalaire (price ÷ price → ratio), et « point + point » n'existe pas du tout — c'est exactement pourquoi close + rsi(close, 14) est refusé plutôt que calculé.

Au-dessus des paires affines, une dimension est un élément d'un groupe abélien d'exposants entiers sur les cinq générateurs {P, V, T, I, rad} — prix, volume, temps, indice ordinal de barre, angle. La multiplication additionne les vecteurs d'exposants, la division les soustrait, de sorte que × et ÷ sont totales sur les dimensions (price × volume → pv est P·V ; pv ÷ volume → price est P¹V¹−V¹). Seules +, − et les comparaisons d'ordre exigent une dimension égale, car ajouter des mètres à des kilogrammes — ou des points à des déplacements d'un axe différent — n'a aucun sens.

fluxgap    = close - close[1]          // level      pt(P) − pt(P) = vec(P)
band   = close + 2 * atr(14)       // price      pt(P) + lit·vec(P) = pt(P)
rel    = close / open              // ratio      P⁰ — dimensionless, centered on 1
flow   = close * volume            // pv         P·V by the group law
speed  = change(close, 5) / (5 bars)  // slope    vec(P) ÷ vec(I) = P·I⁻¹ — price per bar

Trois paires affines vivent dans l'antichaîne, une par axe : price/level sur P, time/duration sur T, et barindex/barspan sur l'axe ordinal I (règle A1 — l'axe des x est affine aussi, donc barindex − barindex → barspan, et une pente de régression est level ÷ barspan → slope = P·I⁻¹, prix par barre, délibérément distincte de P·T⁻¹).

#Les sortes

Le treillis est stratifié en sortes : structure fine à l'intérieur de chaque sorte, et entre sortes la borne supérieure est ⊤ et la borne inférieure est ⊥. Les extrema sont partagés par toutes les sortes : ⊤ (n'importe lequel — le canal d'erreur, dur quand exigé) et ⊥ (jamais — le kind de na, qui habite tout kind : na : ∀κ.κ entre dans le treillis à ⊥ et se subsume vers le haut vers ce qui est attendu).

#La sorte scalaire

Tout ce qui est dans la sorte scalaire siège sous quantity, qui siège sous ⊤.

La colonne vertébrale sans dimension — lit < {ratio, osc(lo,hi), signal, dir, depth} < num :

• lit — un littéral replié en constante (const-folded), polymorphe en dimension : lit ≤safe tout scalaire, dimensionné ou non. C'est ce qui rend close + 10, close > 30000 et nz(x, 0) licites sans cérémonie : le littéral adopte le kind que son contexte lui donne.
• ratio — sans dimension, centré sur 1, multiplicatif (price ÷ price, largeur de bande).
• osc(lo,hi) — sans dimension et borné, une famille paramétrée par intervalle (rsi → osc(0,100), cmo → osc(-100,100), cmf → osc(-1,1)). Voir le sous-treillis d'intervalles ci-dessous.
• signal — un événement booléen, {0,1} (comparaisons, cross_up, rising, in_session).
• dir — une direction, {-1, 0, +1} (règle A6) : catégoriel-discret, le frère plat de signal (dir < num). Il type le champ de direction des structures de tendance (superTrend(…).dir), est présenté comme coloration de barres ou marks, et est discriminé par comparaison (st.dir == 1), jamais par match et jamais par <. (Il n'y a pas de + unaire dans la grammaire : la valeur +1 s'écrit 1.)
• depth — une z-intention sans dimension taggée @z, produite par l'analyse et consommée par le canal z de présentation (projetée en 3-D, aplatie en 2-D).
• num — sans dimension de rôle inconnu : la borne supérieure de la colonne vertébrale. kdj(…).j et les accesseurs calendaires atterrissent ici.

L'antichaîne dimensionnée — chaque élément ≤ quantity, chaque ≥ lit, et tous incomparables deux à deux : price = pt(P) · level = vec(P) · volume = V (valeurs signées autorisées : obv) · pv = P·V (flux monétaire) · time = pt(T) · duration = vec(T) · barindex = pt(I) · barspan = vec(I) · slope = P·I⁻¹ · angle = rad — plus chaque dimension composée que la loi de groupe peut produire (P², P²·V⁻¹, …), qui sont des kinds pleinement traçables présentés dans un pane auto étiqueté par leurs exposants, sans avertissement (règle A3).

quantity — la dimension effacée, borne supérieure de toute la sorte scalaire. C'est ce qu'une borne supérieure dimensionnellement incompatible produit (voir L2 ci-dessous) : toujours traçable, mais suspecte, et toujours signalée. quantity est réservé aux dimensions réellement effacées ou mélangées ; une dimension composée précise comme P² ne s'y dégrade jamais.

#Les sortes catégorielles — color, clock, string

Les kinds catégoriels sont plats (chacun est un seul élément, ne se joignant qu'à lui-même) et vivent hors de l'arithmétique ; chacun est consommé par un éliminateur dédié plutôt que calculé :

• color — une valeur de style RGBA, consommée par les fills, la coloration de barres et les canaux de style (Color).
• clock — un calendrier de rééchantillonnage : un indice ordinal avec les constructeurs tf("1d"), renko(box), pnf(box, rev), range(r). Un clock est une valeur de première classe (on peut en sélectionner un avec un if, en prendre un comme input) mais il n'est éliminé que par @ (Temps et état) ; il n'est jamais tracé et jamais comparé.
• string — texte UTF-8 borné et immuable (règle A12) : étiquettes, invites, messages d'alerte. string est plat comme color et hors de l'arithmétique numérique, avec exactement une surcharge d'opérateur : string + string → string est la concaténation — l'unique ligne catégorielle de la table de règles de +. Il n'y a pas de string < string (le tri dépendant de la locale est exclu par le déterminisme), l'égalité est l'égalité bit-à-bit, et un string est consommé par les canaux attendant du texte — il n'est jamais tracé comme une série (Text).

#Les sortes structurelles — vec et record

Les kinds structurels se composent composante par composante ; les formes non concordantes sont du non-sens et se résolvent aux extrema.

• vec<κ>[n] — un vecteur de κ avec une capacité repliée en constante (const-folded) n (n ≤ N_max = 10 000). Capacité, pas compte exact : voir ci-dessous. Introduit par window(e, n), les littéraux de liste, vec.fill(N, x) et vec.range(N) ; covariant en κ.

  Notation. vec<κ>[n] est le métalangage de cette documentation. Dans le source, le même kind s'écrit vec(κ, N) — avec des parenthèses, car < et > sont exclusivement les opérateurs de comparaison et jamais des délimiteurs de type.

• record{f₁:κ₁, …} — un produit nommé. Cette sorte est porteuse pour le catalogue : une large part des kernels intégrés renvoient des records — bollinger → record{upper, middle, lower: price}, macd → record{macd, signal, hist: level}, superTrend → record{st: price, dir: dir}, adx → record{adx, plusDi, minusDi: osc(0,100)}. La projection est e.f ; la mise à jour fonctionnelle est e with { f: v } (préservant la forme — les champs non listés sont reportés, les champs inconnus sont [ErrField]).

#Les sortes du plan APP — variant et ui

Le plan APP ajoute deux sortes par la même construction, directement sous ⊤, sans rouvrir le treillis fondamental scellé :

• variant{Tag₁:κ₁ | …} — la somme étiquetée, dual catégoriel de record (le produit). Son introduction est l'injection de constructeur Tag(e), son éliminateur est match (symétrique à la projection). L'ordre, la borne supérieure, la borne inférieure et la propagation de ⊤ sont dérivés identiquement à record : les ensembles d'étiquettes sont invariants (mêmes étiquettes → raffiner par charge utile, de façon covariante ; ensembles d'étiquettes différents → incomparables, borne supérieure ⊤, borne inférieure ⊥). Les messages, commandes et souscriptions d'une app sont des variants (Le plan APP).
• ui — la sorte des primitives de vue : un ensemble fermé et vérifié de primitives, plat comme color, consommé par le renderer de l'hôte, et jamais coercible en un scalaire (ui ⊔ κ = ⊤, ui ⊓ κ = ⊥ entre sortes — une primitive en position scalaire est attrapée immédiatement).

#Pas de sorte fonction

Il n'y a délibérément aucun kind flèche dans le treillis. Les lambdas sont de seconde classe : un (p⃗) -> body n'est admis que là où un kernel d'ordre supérieur attend une fonction (window/fold/map/scan/loop, vec.where, sortBy, …) et est inliné à cet endroit. Un lambda ne peut donc jamais être un champ de record, un élément de vec, une charge utile de variant ou une valeur liée par let — c'est ce qui garde chaque valeur représentable comme de simples données, chaque buffer borné, et les artefacts compilés exempts de closures et de pointeurs de fonction. La récursion passe par def (dont le graphe d'appels doit être acyclique — [ErrTotalRec]) ou par un scan/loop borné, jamais par un lambda auto-référençant.

#Le catalogue des kinds

Une ligne par kind. La table de présentation complète (pane/overlay/échelle/guides/classe css par kind) est normative dans Inférence ; la dernière colonne ici est le résumé en une ligne.

decimal(scale), period, le tag d'actif (B,Q[,@v]), meas[u] et metric[id] sont des tags orthogonaux sur ces kinds, pas des kinds à part entière — voir Tags orthogonaux ci-dessous.

#L'ordre partiel

La décision la plus lourde de conséquences dans l'ordre : les dimensions forment une antichaîne, et num est incomparable à chaque dimension — price ⊀ num. Les kinds dimensionnés montent jusqu'à quantity, jamais jusqu'à num.

Pourquoi cette règle existe. Si price ≤ num tenait, alors signal ⊔ price = num — un événement booléen et un price se réconcilieraient silencieusement en un nombre traçable ordinaire, et la détection d'erreurs qui motive tout le système s'évaporerait exactement au moment où elle compte (un co-tracé ou un if mélangeant des choses incompatibles). En routant plutôt tous les kinds dimensionnés vers quantity, un mélange n'est jamais silencieux : en arithmétique il est refusé ([ErrDim]), et en réconciliation de branches il compile vers quantity et est signalé ([WarnBranchDim]) — visible, traçable, suspect.

Descendre l'ordre gagne de l'information, et la présentation lit toujours le kind le plus bas connu — c'est pourquoi l'inférence synthétise le kind minimal (principal) et ne coerce qu'aux sites de consommation (voir Inférence).

#Deux paliers d'arêtes de coercition

Chaque arête de l'ordre est strictement montante, et chaque arête appartient à exactement l'un de deux paliers disjoints :

• ≤safe — silencieux. ⊥ ≤ κ ≤ ⊤ pour tout κ ; l'élargissement des bornes osc (osc(0,100) ≤ osc(-100,100)) ; l'élargissement de la capacité vec (vec<κ>[k] ≤safe vec<κ>[N] pour k ≤ N) ; les arêtes de la colonne {ratio, osc, signal, dir, depth} ≤ num et num ≤ quantity ; et lit ≤ chaque scalaire.
• ≤lossy — compile, avertit, propose un correctif rapide. Effacer une dimension (D ≤ quantity pour tout D dimensionné), et accepter une combinaison affine non normalisée. La perte d'information est licite mais jamais silencieuse.

L'antisymétrie survit parce que les deux paliers montent strictement et ne se chevauchent jamais.

#Polymorphisme littéral

lit est le plancher ergonomique de la sorte scalaire. Un littéral const-folded se coerce en sûreté vers tout scalaire, de sorte que les choses naturelles sont licites sans cérémonie :

fluxhot   = close > 30000              // price vs lit → the lit reads as price → signal
lift  = close + 10                 // lit adopts price → price
safe  = nz(change(close, 1), 0)    // level ⊔ lit = level
shift = rsi(close, 14) - 50        // osc(0,100) − lit → osc(-50,50): interval propagated

Le compilateur linte tout de même les littéraux impossibles contre les bornes revendiquées (rsi(close,14) > 150 est [WarnLit]), car un lit adoptant un kind ne suspend pas le bon sens arithmétique.

#Capacité, pas longueur : vec<κ>[n]

Le n dans vec<κ>[n] est une capacité const-folded — une borne supérieure, pas un compte exact. Un vecteur plus court habite un vecteur plus long via l'élargissement ≤safe vec<κ>[k] ≤safe vec<κ>[N] (k ≤ N), sa queue [k, N) se lisant na. La mémoire reste bornée par le plafond déclaré, donc la totalité tient ; l'itération bornée (map/fold) est consciente de na sur la capacité, de sorte qu'une queue élargie ne contribue rien. [ErrLen] ne se déclenche que lorsque deux capacités déclarées sont réellement incompatibles — sinon l'opérande le plus court s'élargit vers le plus long. C'est aussi pourquoi les littéraux de liste de longueurs différentes se joignent proprement : vec<κ>[k] ⊔ vec<κ>[m] = vec<κ>[max(k,m)].

fluxw    = window(close, 20)           // vec<price>[20] — a specific produced length
wide = nz(w, window(close, 50))   // vec<price>[50] — 20 widens into 50, tail na

Les longueurs non constantes ou au-delà du plafond sont [ErrTotal] (n ≤ N_max = 10 000) — le prix d'une « mémoire totale et bornée » est qu'une capacité est toujours un fait connu à la compilation.

#Borne supérieure et borne inférieure

#Le catalogue de la borne supérieure

κ ⊔ κ = κ           ⊥ ⊔ κ = κ           ⊤ ⊔ κ = ⊤           lit ⊔ κ = κ
osc(L,H) ⊔ osc(L',H') = osc(min L L', max H H')          — the envelope
spine siblings → num          (osc ⊔ ratio = num · dir ⊔ signal = num)
D ⊔ D' (D ≠ D') = quantity    D ⊔ num = quantity    signal ⊔ price = quantity
vec<S>[k] ⊔ vec<T>[m] = vec<S ⊔ T>[max(k,m)]
record{f:A} ⊔ record{f:B} = record{f: A ⊔ B}             — differing field sets → ⊤
variant: same label set → per-payload join                — differing label sets → ⊤
across sorts → ⊤

Deux placements méritent leurs raisons :

• signal ⊔ price = quantity, pas ⊤ (correction L2). quantity est une borne supérieure commune des deux (signal ≤ num ≤ quantity, price ≤ quantity), donc ⊤ ne serait pas la plus petite — et la politique d'erreurs veut exactement ce résultat : la réconciliation de branches de dimensions mélangées est un avertissement ([WarnBranchDim] sur un quantity traçable), tandis qu'une dimension mélangée dans une position arithmétique reste un [ErrDim] dur. La frontière entre dur et doux court entre l'algèbre et la réconciliation, pas à travers le treillis.
• dir ⊔ signal = num, pas quantity. Les deux sont des feuilles de la colonne sans dimension sous num, donc num est leur borne supérieure — exactement comme osc ⊔ ratio = num. Promouvoir vers quantity placerait un élément plus grand au-dessus d'une borne supérieure existante et détruirait l'unicité de la LUB.

Les bornes supérieures atterrissent sur ⊤ exactement là où réside le vrai non-sens : entre sortes (price ⊔ color, num ⊔ record{…}), sur des formes structurelles non concordantes (ensembles de champs ou d'étiquettes qui diffèrent), et — la seule exception énumérée au sein d'une sorte — sur une dimension égale avec des tags de représentation différents ([ErrRepr], ci-dessous). Les simples mélanges de dimensions n'atteignent jamais ⊤ ; ils montent vers quantity et restent visibles.

fluxc = volume > sma(volume, 20)

a = if c then rsi(close, 14) else cmo(close, 14)
        // osc(0,100) ⊔ osc(-100,100) = osc(-100,100) — envelope
b = if c then close else rsi(close, 14)
        // price ⊔ osc = quantity — compiles, [WarnBranchDim], suggest two panes

#Le catalogue de la borne inférieure et la correction lit

⊤ ⊓ κ = κ           ⊥ ⊓ κ = ⊥
quantity ⊓ D = D            num ⊓ ratio = ratio            — a constraint refines
osc ⊓ osc = interval intersection      (disjoint → lit, by L1)
incomparable scalars ⊓ = lit                                — correction L1
across sorts → ⊥            (lit does not cross sorts)
variant/record: same shape → per-component meet — differing shapes → ⊥

La correction L1 est porteuse : la borne inférieure de deux scalaires incomparables — disons price ⊓ volume, ou dir ⊓ signal — est lit, pas ⊥. lit ≤safe les deux opérandes, donc lit est une borne inférieure commune, et la plus grande borne inférieure doit se situer au niveau ou au-dessus de chaque borne inférieure commune ; forcer ⊥ contredirait lit ≤ price ∧ lit ≤ volume ⇒ lit ≤ price ⊓ volume et casserait la loi d'absorption (price ⊓ (price ⊔ level) = price ⊓ quantity = price tient précisément parce que les bornes inférieures raffinent plutôt qu'elles n'annihilent). Au sein de la famille des oscillateurs, la même correction résout l'intersection vide : deux kinds osc d'intervalles disjoints sont des scalaires incomparables, donc leur borne inférieure est lit — l'intervalle vide ∅ n'est le bas que du sous-treillis d'intervalles vu isolément, jamais la GLB globale.

#Le treillis d'intervalles osc

osc(lo,hi) est une famille ordonnée par inclusion d'intervalles : osc(L,H) ≤ osc(L',H') ⟺ [L,H] ⊆ [L',H']. La borne supérieure est l'enveloppe, la borne inférieure est l'intersection, et les bornes peuvent être des constantes infinies : osc(-∞,∞) (règle A4) est le kind de toute la famille du pourcentage de variation (roc, cci, trix, coppock, fisher, kst, chaikinVolatility, volumeOscillator) — sans dimension, centrée sur 0, additive, ce qui la distingue proprement de ratio (centré sur 1, multiplicatif) et de num (rôle inconnu).

Les bornes sont des revendications de présentation, pas des invariants d'exécution. Le kind osc(0,100) assère « ceci est présenté sur une échelle fixe 0–100 avec une ligne médiane » ; seul un clamp explicite rend une borne réelle à l'exécution, et l'arithmétique propage honnêtement les intervalles revendiqués (rsi − 50 → osc(-50,50)). La règle A5 scinde le catalogue en conséquence : une borne réellement imposée par le calcul (rsi, stochastic, mfi, cmf) produit une échelle [lo,hi] fixe ; une borne simplement conventionnelle (adx, correl, balanceOfPower) est une revendication — échelle auto plus guides indicatifs. Une borne qui n'aurait pas réussi à se replier en constante retomberait sur num ; aucun kernel du catalogue n'en produit.

#Propagation profonde de ⊤

vec<⊤>[n], record{f: ⊤, …} et variant{T: ⊤ | …} se réduisent tous à ⊤. Sans cela, une non-concordance enfouie — vec<price> ⊔ vec<color> produisant vec<⊤> — se glisserait sous chaque garde κ ≠ ⊤ et ferait surface comme un mystère d'exécution au lieu d'un diagnostic à la compilation. Une erreur à n'importe quelle profondeur est une erreur de la valeur entière.

#Clôture, vérifiée par énumération

Avec L1 et L2 en place, chaque paire de kinds a une LUB unique et une GLB unique. L'ensemble des kinds est fini par famille structurelle : le cœur dimensionnel est fini, et chaque axe paramétré — bornes osc, capacité vec, échelle et précision decimal, les tags de représentation, les composantes du tag d'actif et l'annotation de paire fx — est un tag const-folded dont les clés sont énumérables au point de vérification. Les lois du treillis (antisymétrie, absorption, unicité de LUB/GLB) sont donc vérifiées par machine par énumération exhaustive, famille par famille — pas simplement argumentées (Garanties). Les déclarations nommées record/variant préservent cela : leur graphe de références doit être acyclique ([ErrTotalType]), de sorte que chaque kind nommé s'aplatit en une structure de hauteur finie.

#L'algèbre des opérateurs en bref

Les tables complètes et normatives par opérateur sont dans Opérateurs. La forme du système B, en un écran — une règle manquante signifie ⊤, d'où [ErrDim] à la consommation :

• ± (dimension égale ; affine) : pt(d) − pt(d) → vec(d) · pt(d) ± vec(d) → pt(d) · vec ± vec → vec · ratio ± ratio → ratio · osc ± osc → intervalle propagé · lit ± x → x · dimensions différentes → ⊤. Une surcharge catégorielle : string + string → string (concaténation), et rien d'autre ne touche string.
• Combinaisons affines ((high + low) / 2) : l'expression est normalisée en Σ λᵢ·ptᵢ avec des coefficients const-folded ; Σλ = 1 → price (un point pondéré), Σλ = 0 → level (un déplacement pur), tout le reste → quantity + [WarnAffine]. Multiplier par un lit préserve le rôle, donc sma(close,20) + 2 * stdev(close,20) se type comme price + level → price. La règle A7 applique ceci après inlining, de sorte que les composites récursifs se typent correctement : dema = 2·ema − ema(ema) a Σλ = 1 → price.
• × et ÷ (la loi de groupe, règle A2) : les vecteurs d'exposants s'additionnent et se soustraient, de sorte que les deux opérateurs sont totaux sur les dimensions — D × ratio → D, price × volume → pv, price × price → P² (traçable, A3), pv ÷ volume → price, pv ÷ price → volume, level ÷ barspan → slope.
• Comparaisons d'ordre (< > <= >= cross_*) : admises uniquement sur la sorte scalaire ordonnée avec des dimensions compatibles (κₐ ⊔ κ_b ∉ {quantity, ⊤}) → signal. price < osc est [ErrDim] ; color, clock, string, record, vec, variant, ui ne sont jamais ordonnés ; dir est catégoriel-discret et hors de l'ordre.
• Égalité (== !=) : égalité décidable → signal — égalité bit-à-bit pour les scalaires, string, dir, color ; égalité profonde, consciente de na pour record/vec/variant (formes non concordantes → [ErrDim]) ; clock et ui sont consommés, jamais comparés ([ErrArg]).
• Logique (and or not) : signal × signal → signal — il n'y a pas d'arithmétique sur signal.

fluxtrend = ema(close, 50)                    // price   ([CallPoly]: α = price)
hits  = count(close cross_up trend, 20)   // osc(0,20) — const-folded n
since = barssince(close cross_up trend)   // barspan — a bar count, not a num
bad   = close < rsi(close, 14)            // ✗ [ErrDim] — price ⊔ osc = quantity

#Tags orthogonaux

Au-delà de sa dimension, un kind peut porter jusqu'à trois tags orthogonaux, plus un axe qui ne vit que sur ratio :

1. un tag de représentation numérique — f64 (défaut) ou decimal(scale) (règle A11) ;
2. un tag de représentation du temps sur la dimension T — machine (défaut ; temps écoulé exact — duration) ou calendar (period, règle A10) ;
3. un tag d'actif — un n-uplet à arité fixe à clés-chaînes (B, Q [, @v]) sur les kinds de dimension prix (règle A9) ;

plus (4) l'annotation de paire de devises de fx — un axe porté uniquement par ratio, dont le sommet est le ratio nu lui-même. Comme ratio ne porte jamais de tag d'actif, aucun kind ne porte jamais quatre tags : un decimal price[BTC,USD] en détient trois (représentation + actif + dimension), et c'est le plafond.

Les deux familles d'axes obéissent à deux régimes différents — et la différence est le point essentiel :

• Les tags de représentation (1, 2) ne coercent jamais silencieusement. Sur deux kinds de dimension égale mais de tags de représentation différents, la borne supérieure et la borne inférieure produisent ⊤ — faisant surface comme [ErrRepr] dans une position exigeante. Le seul pont est une conversion explicite (toDecimal / toFloat ; les constructeurs period pour le temps calendaire). Ceci reflète le refus arithmétique : on n'ajoute pas un f64 price à un decimal price, ni un duration machine à un period calendaire, sans le dire.
• Le tag d'actif (3) s'élargit par composante. Chaque composante a son propre sommet (⊤base, ⊤quote, ⊤venue) ; une borne supérieure élargit la composante qui diffère et préserve celle qui concorde — price[B1,Q] ⊔ price[B2,Q] = price[⊤base, Q] — et ne lève jamais [ErrRepr]. La sûreté vient non pas de la borne supérieure mais de l'algèbre ± taggée : +, −, les comparaisons et la règle affine exigent toutes des tags identiques composante par composante, et refusent avec [ErrDim] sinon. L'élargissement garde la composition possible (les price[BTC,USD] de deux places peuvent former un indice) ; la barrière d'identité attrape encore chaque bug d'unité.

Pour les deux régimes, des tags identiques retombent sur les règles de dimension simples avec le tag préservé à travers ± × ÷ : decimal price − decimal price = decimal level, period + period = period, price[BTC,USD] − price[BTC,USD] = level[BTC,USD].

#Représentation numérique — f64 et decimal(scale)

decimal(scale) est un virgule fixe exact, orthogonal à la dimension : un decimal a toujours une dimension, et la loi de groupe est inchangée (money ÷ qty → price avec money ≡ pv, qty ≡ volume). L'échelle (scale) chevauche le kind et le système la calcule : ± prend le max des deux échelles, × les additionne, et ÷ est la seule opération non close — elle requiert une échelle cible et un mode d'arrondi explicites. La précision déclarée choisit le support le plus étroit (i64/i128/i256) ; dépasser la précision déclarée produit un na déterministe plus un diagnostic, jamais un débordement silencieux. Les littéraux sont suffixés : 1.50d est decimal(2), 1.5 est f64. Le domaine du decimal est l'argent réglé — montants d'ordres, fills, soldes ; les kernels d'analyse restent f64.

fluxexact = toDecimal(close, 2)        // decimal(2) price — explicit entry, rounds
bad   = close + exact              // ✗ [ErrRepr] — f64 price + decimal price
worse = if c then close else exact // ✗ [ErrRepr] — the join refuses the same mixture
fine  = toDecimal(close * volume, 2) + toDecimal(close * volume, 2)  // decimal(2) pv — a money amount adds; same representation, scales combine

#Représentation du temps — machine et calendaire

time = pt(T) est un instant (une époque int64 sous le capot) ; duration = vec(T) est le temps machine écoulé exact. period est le même vec(T) taggé calendar — une quantité en mois-et-jours consciente des fuseaux et des transitions d'heure d'été. t + duration et t + period sont tous deux dimensionnellement pt(T) + vec(T) → pt(T) ; le tag est ce qui sépare « exactement 24 heures plus tard » de « la même heure d'horloge demain », et les deux ne se mélangent jamais silencieusement :

fluxage    = time - time[20]                 // duration — machine-exact
renew  = time + time.months(1)           // time — calendar arithmetic, DST-aware

// ✗ (time - time[20]) + time.months(1)  — [ErrRepr]: a duration and a period do not add

Les valeurs period ne sont produites que par les constructeurs time.years/months/weeks/days(n) (composables : time.months(1) + time.days(10)) ; les accesseurs calendaires (year, dayOfWeek, …) projettent un time dans une zone déclarée en tant que num, et l'arithmétique calendaire hors plage produit un na déterministe, jamais un débordement. La base de données de fuseaux horaires épinglée et la routine de conversion partagée qui rendent ceci reproductible sont spécifiées avec le pilier compute (Compute).

#Le tag d'actif — (B, Q [, @v])

Un price n'est jamais un nombre nu : c'est un taux, quote-par-base. Le tag d'actif rend cette identité dimensionnelle, par kind :

La quote chevauche chaque dimension contenant le facteur P (y compris P² composé, slope) ; les kinds sans dimension ne portent aucun tag d'actif. Le défaut est mono-actif price[primary, baseccy], byte-identique à un script mono-série qui ne mentionne jamais l'axe ; les tags ne deviennent concrets que là où les clés de séries sont des littéraux statiques, et s'élargissent vers les sommets de composantes sinon. La composante de place @v est sur activation (désactivée par défaut ; l'absence est le niveau composite concret, pas ⊤venue).

fluxc      = volume > sma(volume, 20)
btcUsd = series("BTC-USD").close        // price[BTC,USD]
btcEur = series("BTC-EUR").close        // price[BTC,EUR]
ethUsd = series("ETH-USD").close        // price[ETH,USD]

diff   = btcUsd - btcUsd[1]             // level[BTC,USD]
mixA   = btcUsd + ethUsd                // ✗ [ErrDim] — mixing assets
mixQ   = btcUsd + btcEur                // ✗ [ErrDim] — mixing currencies
cmpQ   = btcUsd < btcEur                // ✗ [ErrDim] — comparisons gate on identity too
rel    = btcUsd / ethUsd                // ratio — cross-base relative strength, tag dropped
either = if c then btcUsd else btcEur   // price[BTC,⊤quote] — the join widens, never errors

#fx et money — des kinds existants, taggés

La conversion de devises n'a besoin d'aucune nouvelle sorte. fx[Q1/Q2] est le kind ratio portant une annotation de paire de devises optionnelle et ordonnée — le quatrième axe de tag, ne vivant que sur ratio, sommet = le ratio nu. money[Q] est un alias pour decimal pv[Q]. Zéro nouvelle sorte, zéro nouvelle hauteur de treillis. Un fx naît d'une division de prix de même base et de quote différente, ou d'un flux déclaré comme série fx ; la conversion est une annulation d'unités vérifiée par les types :

fluxc         = volume > sma(volume, 20)
btcUsd    = series("BTC-USD").close
btcEur    = series("BTC-EUR").close
eurGbp    = series("EUR-GBP").close      // an fx series, declared as one

usdPerEur = btcUsd / btcEur             // fx[USD/EUR] — same base, quotes differ
inUsd     = btcEur * usdPerEur          // price[BTC,USD] — the shared quote cancels
flipped   = 1 / usdPerEur               // fx[EUR/USD] — the reciprocal edge
avg       = if c then usdPerEur else eurGbp   // ratio — differing pairs join to bare ratio

Une non-concordance de paire dans ×/÷ s'élargit vers ⊤quote plutôt que d'échouer (le régime × n'échoue jamais durement) ; l'annotation de paire est exclue de la barrière d'identité de comparaison, de sorte que deux taux fx se comparent toujours comme les ratios qu'ils sont. Le catalogue complet des arêtes — dérivation, réciproque, chaînage triangulaire, conversion dans les deux ordres d'opérandes — est dans Actifs et devises.

#Annotations d'unité et de métrique

Deux axes de tags supplémentaires étendent la même construction au-delà de la finance, tous deux portés par num seul, tous deux avec le num nu comme sommet :

• meas[u] (règle A14) — quantités généralistes : une annotation d'unité dont u est un produit de symboles de catalogue à exposants entiers (meas[m], meas[m·s⁻¹], meas[kg·m·s⁻²]), augmentée d'un bit point|delta affine pour les échelles à zéro arbitraire (un point unit.tempC(20) versus un déplacement unit.tempCDelta(5) — la même discipline point/vecteur que price/level, appliquée à la température). ± et les comparaisons filtrent sur des unités identiques ; ×/÷ composent les cartes d'exposants avec des facteurs de conversion épinglés exacts et s'annulent complètement en ratio ; les produits mixtes avec les kinds dimensionnés financiers sont un mur explicite ([ErrDim]). L'algèbre complète, le verbe de conversion et les règles d'entrée vivent dans Unités.

fluxwarm = unit.tempC(20) + 5                // a point ± lit → point — the lit reads as a delta
span = unit.tempC(25) - unit.tempC(20)   // point − point → a 5-degree delta

• Réservé. metric[id] (règle A15) — annotations d'identité pour les séries non-prix (indices macro, métriques on-chain, analytics). Le ± de même id préserve, des ids différents refusent (classe [ErrDim]), metric[A] ÷ metric[B] → ratio, et les familles préservant le kind portent l'annotation à travers. L'axe est délibérément inerte en v1 — aucune série non-prix n'entre dans le plan ANALYSIS tant que l'amendement n'est pas armé ; sa conception est spécifiée avec Actifs et devises.

#Records et variants nommés

Les kinds structurels peuvent être déclarés et nommés au niveau du programme :

fluxrecord Band { upper: price, middle: price, lower: price }

variant Tool  { Select | Draw | Erase }
variant Save  { Saved | Failed(code: num) }

t = Tool.Select                     // qualified constructor — resolves homonyms
s = Save.Saved                      //   across variants that share a label

Un constructeur nullaire est lu comme une valeur de son variant ; un constructeur portant une charge utile est appliqué comme une fonction, sa charge utile vérifiée contre les kinds de champs déclarés. La forme qualifiée T.C sélectionne le constructeur du variant nommé T — résolue à la résolution de noms, avant que la projection de champ ne s'applique jamais, de sorte que les collisions d'étiquettes entre variants sont un non-problème.

Deux disciplines maintiennent les déclarations nommées à l'intérieur des garanties du treillis scellé :

• Les records sont monomorphes en v1. Un def qui projette un champ requiert un kind de record concret connu à l'inférence. Post-v1. une extension à lignes ouvertes (polymorphisme de lignes) est une extension additive nommée — jamais un prérequis v1.
• Le graphe de références doit être acyclique. Un record/variant déclaré peut référencer d'autres déclarations nommées, mais tout cycle — direct ou transitif — est rejeté à la résolution de noms avec [ErrTotalType], le jumeau au niveau kind du graphe d'appels def acyclique ([ErrTotalRec]). Chaque kind nommé s'aplatit donc en une structure de hauteur finie, et la propriété de hauteur finie sur laquelle reposent la clôture et la vérification par machine s'étend inchangée aux déclarations utilisateur.

fluxrecord Node { next: Node }          // ✗ [ErrTotalType] — cyclic reference, unbounded height

#Un exemple détaillé : le treillis refuse la mauvaise physique

Le graphique Point & Figure est un test de stress que le système de kinds passe sans un seul nouveau kind — et il montre la lentille dimensionnelle à l'œuvre pour de vrai. Chaque pièce reçoit son kind naturellement : pnf(box, rev) est un clock ; l'état de colonne est un scan sur un simple record ; et la taille de boîte doit être un level, parce que la géométrie l'exige :

fluxbox    = atr(14)                    // level — a displacement, by construction
anchor = close                      // price — a point
edge   = anchor + 3 * box           // price ✓ — pt(P) + lit·vec(P) = pt(P)

// the column state the frontier belongs to — a plain bounded scan over a record
state  = scan({ dir: 1, extreme: close, count: 0 },
               (p) -> if close > p.extreme + box
                        then { dir: 1, extreme: close, count: p.count + 1 }
                        else p)

Supposez que vous ayez déclaré la boîte comme un price. Alors anchor + box serait price + price — point + point, aucun sens affine — et le compilateur répond [ErrDim] sur-le-champ. Le treillis ne fait pas que permettre le modèle correct ; il refuse le modèle incorrect. La même lentille type le reste de l'état : count est un compte de boîtes sans dimension (num), donc count * box est num · vec(P) → level et extreme + count * box retombe sur price ; et count n'est délibérément pas un barspan — les boîtes ne sont pas des barres, et les kinds empêchent les deux comptages d'être jamais confondus.

#Erreurs et na au niveau kind

La politique d'erreurs complète — y compris les diagnostics de causalité, de totalité et de pare-feu — est spécifiée dans Inférence ; le squelette au niveau kind est :

• Dure ([ErrDim], [ErrRepr], [ErrLen], [ErrField], [ErrArg], [ErrPlot], [ErrTotalType], [ErrTotalMatch]) : une garantie porteuse est violée ou le non-sens est certain — un ⊤/⊥ dans une position exigeante, une condition annexe violée, une non-concordance de forme.
• Avertissement ([WarnTop], [WarnAffine], [WarnBranchDim], [WarnBoundsØ], [WarnLit]) : suspect mais possiblement intentionnel, ou une perte d'information récupérable — exactement le palier ≤lossy et le cas du ⊤ mort.

na mérite son énoncé au niveau kind : na synthétise ⊥ et se subsume dans tout kind attendu, de sorte que l'absence est une valeur de tout kind, jamais une forme séparée. Le na d'exécution se propage à travers l'arithmétique avec le kind préservé, et toute comparaison touchant na est elle-même na — jamais true ni false. On teste l'absence explicitement :

fluxm   = sma(close, 200)               // price — na during warm-up
odd = m == na                       // legal, but always na — never true
hit = is_na(m)                      // signal — the way to ask
has = is_some(m)                    // signal — its dual

Un match sur un sujet possiblement na doit le couvrir (un bras na ou _), et déstructurer un record na produit na dans chaque champ — l'absence se compose structurellement, sans cas particuliers à mémoriser.

#Voir aussi

• Opérateurs — l'algèbre dimensionnelle complète par opérateur, UFCS, with.
• Inférence — inférence de kinds bidirectionnelle, inférence de présentation, la politique d'erreurs, na.
• Temps et état — flux, delay, clocks et @, causalité.
• Unités — l'algèbre meas[u] complète : conversions, échelles affines.
• Actifs et devises — le tag d'actif, fx et money, les places.
• Piliers de conception — comment le dimensionnel rejoint les autres piliers.

Opérateurs et sémantique des expressions

Cette page est la référence pour la couche opérateurs de Flux : ce que signifie chaque opérateur, quels kinds il accepte, quel kind il produit, et pourquoi chaque règle est ce qu'elle est. Elle couvre l'algèbre dimensionnelle de + - * /, les deux familles de comparaison, la logique sur signal, le delay x[n], le rééchantillonnage e @ clock, les ranges, l'indexation et la projection, la syntaxe de méthode UFCS, la mise à jour de record avec with, la déstructuration, la famille de sucre ?, le placeholder _, et la table de précédence complète. La façon dont les kinds sont assignés à des programmes entiers — synthèse, vérification, principalité — est le sujet de l'Inférence ; le treillis sur lequel les opérateurs calculent est défini dans Kinds.

Une note sur les échantillons. Flux n'a pas d'instructions-expressions, donc une expression nue n'est pas un programme. Les lignes marquées ✗ sur cette page sont donc des fragments d'expression : elles existent pour montrer ce que les règles de kinds refusent, pas ce que le parser accepte. Chaque ligne non marquée est une instruction licite.

#Une algèbre, deux systèmes

Deux systèmes distincts coopèrent sous chaque expression, et les garder séparés est ce qui rend les règles ci-dessous prévisibles :

• Le treillis de coercition (A). a ≤ b signifie « a se coerce en b sans mentir ». Sa borne supérieure ⊔ unifie les kinds aux sites de réconciliation — les branches d'un if, les deux opérandes de nz, les séries co-tracées. Sa borne inférieure ⊓ intersecte les contraintes — le kind qu'un paramètre exige, les bornes osc qui se recouvrent.
• L'algèbre des opérateurs (B). + - * / < > == sont régis par une table de règles — l'analyse dimensionnelle dans la tradition des vérificateurs d'unités de mesure — qui calcule le kind résultat de chaque application. Ce n'est pas la borne supérieure : price - price = level, tandis que price ⊔ price = price.

Les deux systèmes signalent l'échec via un seul canal d'erreur : toute règle non définie de (B) et toute incompatibilité de (A) produisent ⊤. Un ⊤ est une erreur dure uniquement dans une position exigeante (un opérande, une cible de plot, un argument) ; un ⊤ lié à un nom intermédiaire que rien ne consomme est un avertissement ([WarnTop]). La politique est détaillée dans Inférence.

Le substrat affine. L'axe des prix est un espace affine à une dimension : price est un point dessus, level est un vecteur (un déplacement), ratio est un scalaire sans dimension centré sur 1. La dimension elle-même est un groupe abélien d'exposants sur les générateurs {P prix, V volume, T temps, I indice-de-barre, rad angle} : * additionne les exposants, / les soustrait. Deux conséquences en découlent gratuitement :

• * et / sont totales sur les dimensions — il y a toujours un vecteur d'exposants résultat ;
• seules + et - exigent un accord dimensionnel, car ajouter un point à un point n'a aucun sens géométrique.

Pourquoi cette règle existe. La lecture affine n'est pas une décoration ; c'est ce qui permet au vérificateur de dire non à close + rsi(close, 14) tout en acceptant close + atr(14) — les deux sont « un prix plus un nombre » pour un œil non typé, mais un seul des deux nomme un déplacement sur l'axe des prix. Chaque règle ci-dessous est une instance de ce substrat, pas un cas particulier.

#Addition et soustraction : + et -

+ et - requièrent des opérandes de la même dimension et suivent ensuite les règles affines :

fluxspread   = close - open                  // price − price : level
band     = close + 2 * atr(14)           // price + level : price
centered = rsi(close, 14) - 50           // osc(0,100) − lit : osc(−50,50)
close + rsi(close, 14)                   // ✗ [ErrDim] — point + dimensionless: no affine meaning
obv() + close                            // ✗ [ErrDim] — volume and price do not add

La ligne osc mérite une note : les bornes d'un osc(lo,hi) sont une revendication de présentation, pas un invariant d'exécution (seul clamp rend une borne réelle), et ± propage la revendication par arithmétique d'intervalles. Soustraire la ligne médiane d'un oscillateur recentre donc son pane : rsi - 50 est dessiné dans un pane fixe [-50,50] avec une ligne médiane à 0.

Il n'y a pas d'arithmétique sur signal — combinez les signaux avec and/or/not (voir Logique), comptez-les avec count(sig, n).

#La seule surcharge catégorielle : la concaténation de chaînes

L'unique ligne d'opérateur hors de la table dimensionnelle est la concaténation : string + string → string. - * / et chaque paire mixte impliquant string restent hors de l'arithmétique et produisent [ErrDim].

fluxlabel = "px " + fmt.price(close) + " @ " + fmt.time(time)   // string
"holdings: " + volume                                       // ✗ [ErrDim] — format it: fmt.num(volume)

L'interpolation ("px {fmt.price(close)}") se désucre vers le même pipeline de concaténation (fmt.cat), de sorte que les deux écritures sont équivalentes ; les chaînes de + fusionnent en une seule écriture bornée à la compilation. Voir text pour les garanties du kind string.

#Combinaisons affines : la règle Σλ

Une somme pondérée de points a un sens exactement quand ses coefficients le disent. Sur une expression normalisée en Σ λᵢ · ptᵢ (les coefficients sont des littéraux const-folded, donc x * 0.5 et x / 2 sont le même λ, et (2*high + low + close) / 4 se normalise bien), le vérificateur applique [Affine] :

• Σλ = 1 → le kind point — un barycentre de prix est un price : (high + low) / 2 : price ;
• Σλ = 0 → le kind vecteur — une combinaison à somme nulle est un déplacement : high - low : level ;
• tout le reste → quantity + [WarnAffine] — dimension effacée, probablement un diviseur manquant. high + low seul (Σλ = 2) attire l'avertissement avec un correctif rapide : diviser par 2 ou utiliser la source pré-typée hl2.

Deux raffinements font que cette règle couvre l'algèbre réelle des indicateurs :

• Un coefficient littéral préserve le rôle : k * stdev(close, 20) est toujours un level, c'est pourquoi sma(close, 20) + 2 * stdev(close, 20) se type comme price + level → price — une bande de volatilité atterrit sur le graphique, pas dans un pane. (Le déroulé complet ascendant de cette expression exacte, se terminant par sa décision de présentation, est tracé dans Inférence.)
• La règle s'applique aux composites, récursivement, après inlining — pas seulement aux moyennes OHLC syntaxiques. dema = 2*ema(close,20) - ema(ema(close,20),20) a Σλ = 1 et se type comme price ; tema aussi. Sans application récursive, chaque composite multi-ema se typerait à tort comme level.

Les barycentres OHLC courants sont des sources pré-typées (hl2, hlc3, ohlc4 : price), de sorte que le cas à 90 % n'exerce même jamais la règle.

Les tags d'actif filtrent la combinaison. Tous les points d'une même combinaison affine doivent porter le même tag d'actif, composante par composante, exactement comme ± l'exige (voir ci-dessous) :

fluxbtcUsd = series("BTC-USD").close         // price[BTC,USD]
btcEur = series("BTC-EUR").close         // price[BTC,EUR]
mid    = (btcUsd + btcEur) / 2           // ✗ [ErrDim] — quotes differ; convert one leg first

Pourquoi cette règle existe. Sans la clause de tag, (btcUsd + btcEur) / 2 se normaliserait en Σλ = 1 et passerait la vérification de types comme un price valide, moyennant silencieusement deux devises. La règle affine ne doit pas être une porte dérobée contournant l'interdiction de mélange.

#Multiplication et division : * et /

* et / sont totales sur les dimensions : le vecteur d'exposants du résultat est la somme (respectivement la différence) de ceux des opérandes. Les kinds nommés sont les vecteurs d'exposants que vous rencontrez le plus souvent ; toute autre combinaison est toujours une dimension composée valide et traçable étiquetée par ses exposants (eom : P²·V⁻¹ reçoit un pane auto — aucun avertissement, car une dimension composée précise n'est pas une dimension effacée).

fluxrel   = close / close[1]                     // ratio — centred on 1, own pane
flow  = close * volume                       // pv — money flow, own pane
vwap0 = cum(close * volume) / cum(volume)    // price — back on the chart

Notes sur les cas limites :

• slope est prix-par-barre, pas prix-par-seconde : l'axe des x est ordinal, donc level ÷ barspan → slope = P·I⁻¹. Diviser un level par une duration produirait P·T⁻¹, une dimension différente (et rarement voulue). lrSlope renvoie slope pour cette raison — dérivé de la loi de groupe, pas décrété.
• sqrt divise les exposants par deux et pow(x, n) les met à l'échelle, ce qui est la raison pour laquelle stdev = sqrt(variance) se type correctement ; les transcendantales (log, exp, trigonométrie) exigent une entrée sans dimension — log(close / close[1]) est correct ; le pilier compute fait de log(close) un [ErrDim], avec un correctif rapide vers le ratio.
• Décision ouverte. La grammaire garde % au palier multiplicatif ; aucun kernel du catalogue ne l'utilise et sa conservation est un point ouvert nommé du plan de grammaire. Sa sémantique entière sur les alias entiers long (≡ decimal(18,0)) et long128 (≡ decimal(38,0)) est épinglée (troncature vers zéro ; le reste prend le signe du dividende ; la division par zéro et MIN / −1 produisent na, jamais un trap). Voir compute.

#Tags d'actif et de devise sous les opérateurs

Les kinds de dimension prix portent un tag d'actif (B, Q[, @v]) — base, quote, place optionnelle ; volume porte la base seule, pv la quote seule. Les opérateurs traitent le tag avec deux régimes différents, et la séparation est délibérée :

• ± et les comparaisons filtrent sur l'identité — mélanger lève [ErrDim] ;
• *, / et la borne supérieure élargissent — une composante différente monte vers son sommet par composante (⊤base, ⊤quote), jamais une erreur.

fluxbtcUsd = series("BTC-USD").close      // price[BTC,USD] — a quote-tagged close
d = btcUsd - btcUsd[1]     // level[BTC,USD] — tag preserved through ±
btcUsd + ethUsd            // ✗ [ErrDim] — bases differ: adding two assets
btcUsd + btcEur            // ✗ [ErrDim] — quotes differ: adding two currencies
pnlUsd + pnlEur            // ✗ [ErrDim] — pv[USD] + pv[EUR]: convert first

La division dérive les taux de change, et la multiplication les consomme — la règle du rôle fx :

fluxbtcUsd = series("BTC-USD").close      // price[BTC,USD]
btcEur = series("BTC-EUR").close      // price[BTC,EUR]
ethUsd = series("ETH-USD").close      // price[ETH,USD]
fxUE  = btcUsd / btcEur    // fx[USD/EUR] — same base, quotes differ, concrete keys
cross = btcUsd / ethUsd    // ratio       — cross-base: relative strength, tag dropped
usd   = btcEur * fxUE      // price[BTC,USD] — shared quote cancels: (EUR/BTC)·(USD/EUR)
usd2  = btcEur / (1 / fxUE)          // ÷ fx[EUR/USD] converts the same way

// triangular chaining — both operands are DERIVED; no primitive conjures a rate
btcGbp = series("BTC-GBP").close      // price[BTC,GBP]
gbpEur = btcGbp / btcEur              // fx[GBP/EUR]
usdGbp = fxUE / gbpEur                // fx[USD/EUR] ÷ fx[GBP/EUR] → fx[USD/GBP]

La liste complète des arêtes, en un seul endroit — l'aiguillage price ÷ price est un 2×2 sur (base égale ?, quote égale ?) :

• price[B,Q] ÷ price[B,Q] → ratio (les deux égales) · price[B1,Q] ÷ price[B2,Q] → ratio (la base diffère) · price[B1,Q1] ÷ price[B2,Q2] → ratio (les deux diffèrent — aucune conversion propre n'existe, donc le tag est abandonné et vous obtenez un nombre sans dimension nu) ;
• price[B,Q1] ÷ price[B,Q2] → fx[Q1/Q2] — uniquement quand les deux clés de quote sont des constantes concrètes ; si l'une ou l'autre est ⊤quote, le résultat retombe sur un simple ratio ;
• price[B,Q1] * fx[Q2/Q1] → price[B,Q2] (commutative) et price[B,Q1] / fx[Q1/Q2] → price[B,Q2] — conversion ; la quote partagée doit correspondre chaîne pour chaîne, sinon le résultat s'élargit vers price[B,⊤quote] (jamais [ErrDim] : la sûreté est réservée à ±) ;
• level et pv se convertissent par les deux mêmes arêtes ;
• 1 / fx[Q1/Q2] → fx[Q2/Q1] — la réciproque ; le numérateur doit être le littéral 1, apparié avant toute coercition. Une mauvaise direction est un tag distinct (fx[USD/EUR] ≠ fx[EUR/USD]), jamais une coercition ;
• fx[A/Q] ÷ fx[B/Q] → fx[A/B] — chaînage triangulaire ; fx * fx → num (l'annotation de paire n'a pas d'emplacement sur num) ;
• fx ± fx → ratio — une somme de taux est une magnitude, pas un taux, donc l'annotation de paire disparaît (les kernels sont différents : ema(fxUE) garde fx[USD/EUR]) ;
• price[B,Q] * volume[B] → pv[Q] — la base s'apparie et est abandonnée : un flux monétaire est un montant en devise, agnostique à la base, donc les pv[USD] de deux actifs différents peuvent être sommés — c'est de l'arithmétique de portefeuille, pas le bug de mélange d'actifs ;
• le * inter-actifs s'élargit : price[B1,Q1] * price[B2,Q2] → P²[⊤base,⊤quote], jamais une erreur.

Il n'y a pas de primitive fxRate(a, b) : une valeur fx est dérivée par ÷ ou arrive comme une série dont le producteur se déclare flux fx. Le modèle complet — métadonnées de place, toSource, séries multi-devises — est spécifié dans asset-currency.

#Comparaisons : deux familles, deux portées

Un unique test « la borne supérieure est définie » serait la mauvaise barrière : κ ⊔ κ = κ rend toute borne supérieure d'un kind avec lui-même admissible, y compris les kinds sans ordre et sans égalité utile. Flux cantonne plutôt chaque famille de comparaison aux sortes où son sens est réel. Les deux familles renvoient signal.

#Ordre : < > <= >= cross_up cross_down

Les comparaisons d'ordre sont restreintes à la sorte scalaire avec un vrai ordre total, et les deux côtés doivent être dimensionnellement compatibles (κₐ ⊔ κᵦ ∉ {quantity, ⊤}) :

• ordonnés : la colonne vertébrale numérique (ratio, osc(·), signal, num) et l'antichaîne dimensionnée (price, level, volume, pv, time, duration, barindex, barspan, slope, angle) ;
• exclus : color, clock, string, record, vec, variant, ui — [ErrDim] / [ErrArg]. string < string est rejeté délibérément : le cœur n'a pas de tri dépendant de la locale (une exclusion de déterminisme — voir text) ;
• dir est exclu de l'ordre : {-1, 0, +1} est catégoriel-discret, pas une magnitude. Comparez-le uniquement avec ==.

fluxbreakout = close > 30000                       // price ⊔ lit = price → signal
overbought = rsi(close, 14) > 70               // osc vs lit → signal
golden = ema(close, 50) cross_up ema(close, 200)  // signal — true on the crossing bar
close > rsi(close, 14)      // ✗ [ErrDim] — price ⊔ osc = quantity: incomparable magnitudes
tf("1d") < tf("4h")         // ✗ [ErrDim] — a clock has no order to compare on
superTrend(10, 3).dir > 0   // ✗ [ErrDim] — dir is categorical: write dir == 1

cross_up / cross_down sont des opérateurs de comparaison infixes (jamais des appels préfixes) : a cross_up b est vrai exactement à la barre où a passe d'en dessous-ou-égal à au-dessus de b. Ils siègent au palier de comparaison et sont non associatifs comme le reste.

Les tags d'actif filtrent aussi l'ordre : les opérandes doivent porter des tags identiques composante par composante — price[BTC,USD] < price[BTC,EUR] est [ErrDim] même si la borne supérieure des deux côtés s'élargirait vers un price valide. L'annotation de paire fx est exemptée de la barrière (elle vit sur ratio, hors de l'axe d'actif) : fxUE < fxGJ → signal compare deux taux comme de simples ratios.

#Égalité : == et !=

L'égalité va plus loin que l'ordre — sur chaque sorte dont l'égalité est décidable et terminante :

• égalité bit-à-bit pour string, dir, color — et l'égalité scalaire ordinaire sur la colonne vertébrale (close == open) ;
• égalité profonde, décidable, consciente de na pour record, vec, variant — composante par composante ; deux formes qui diffèrent sont [ErrDim] ;
• exclus : clock et ui sont des kinds consommés, jamais comparés — [ErrArg] ;
• opérandes scalaires de dimensions ou de tags d'actif différents : [ErrDim], exactement comme pour l'ordre ; l'annotation de paire fx est de nouveau exemptée.

fluxst = superTrend(10, 3)
mark st.dir == 1                        // dir compares by equality → signal
bb   = bollinger(close, 20)
same = window(close, 4) == window(close, 4)   // deep, na-aware equality on a vec → signal
tf("1d") == tf("1d")                    // ✗ [ErrArg] — clock is consumed, not compared

#Comparaisons et na

Toute comparaison touchant na produit na — jamais true, jamais false : na == x, na < x, même na == na sont tous na. L'absence est testée explicitement :

fluxhave = is_some(rsi(close, 14))     // signal — presence (not is_na(x))
gap  = is_na(close[1])             // signal — absence (first bar)

Pourquoi cette règle existe. Pendant l'échauffement, un indicateur est na pour ses premières barres. Si na > 70 s'évaluait silencieusement à false, chaque règle de seuil se déclencherait — ou refuserait de se déclencher — sur des données fantômes, et le bug serait invisible par construction. Forcer na à travers les comparaisons fait propager l'absence jusqu'au signal, où is_na / is_some la gèrent délibérément. La même discipline traverse tout le langage : match doit couvrir na, et les réducteurs de fenêtre le propagent.

#Logique : and, or, not

Les opérateurs logiques sont définis sur signal et seulement sur signal (signal × signal → signal) ; not est un opérateur préfixe d'un palier plus serré qu'and.

fluxsetup = close > ema(close, 50) and rsi(close, 14) < 30
flat  = not in_session("09:30-16:00 America/New_York")
close and volume        // ✗ [ErrArg] — `and` demands signals; neither operand is one

Il n'y a pas d'effet de court-circuit à proprement parler — les expressions sont pures — donc and/or sont de la simple algèbre booléenne sur le support {0,1}, conscients de na comme tout le reste.

#Delay : x[n]

x[n] lit la valeur du flux x d'il y a n barres. L'index doit être un littéral naturel const-folded :

fluxmom   = close - close[10]          // level — momentum as a displacement
prevH = macd(close).hist[1]        // projection, then delay — postfix chain
close[-1]                          // ✗ [ErrCausal] — the future is not addressable
close[input(5)]                    // ✗ [ErrTotal] — delay must be a compile-time constant

• n ≥ 0 ; x[0] est x lui-même. Un index négatif est [ErrCausal] : Flux est no-repaint — une valeur, une fois produite pour un pas, ne change jamais — et une lecture dans le futur n'est pas une violation de style mais un programme inexprimable.
• Un index non constant est [ErrTotal] : la profondeur de delay dimensionne un ring buffer, et la totalité exige que toute la mémoire soit bornée à la compilation.
• Sur les n premières barres, x[n] est na (échauffement), ce que les règles de comparaison ci-dessus portent ensuite en sûreté.

La même syntaxe de crochets sur un récepteur vec n'est pas un delay mais une lecture d'élément ([Index]) : slots[h.slot] prend un index ordinal d'exécution, et une lecture hors bornes produit na plutôt qu'une erreur — la capacité déclarée borne déjà le coût. Les deux rôles sont distingués par le kind du récepteur, jamais par de la devinette ; voir Indexation et projection.

#Rééchantillonnage : e @ clock

@ est l'éliminateur du kind clock : e @ c re-cadence le flux e sur la clock c et préserve le kind de e ([At]). Les clocks sont des valeurs de première classe — composables, assignables, acceptables comme input — et @ est la façon dont elles sont consommées :

fluxcalm   = atr(14) < atr(50)                 // signal — a quiet-volatility regime
daily  = ema(close @ "1d", 50)             // MTF: a daily EMA under any chart timeframe
bricks = close @ renko(atrBox(14))         // representation change = clock change
c      = if calm then tf("1d") else tf("4h")
trend  = ema(close @ c, 20)                // the clock itself was computed

• Le rééchantillonnage est causal : à toute barre, il voit l'unité en cours ou la dernière unité close de la clock plus grossière, jamais une clôture future. [ErrCausal] garde le reste.
• Constructeurs : tf("1d"), renko(box), pnf(box, rev), range(r) — où box est un level (le treillis le force : une frontière de brique est anchor + k·box, et seul price + level est un price).
• v1 autorise une clock par série : composer deux clocks (renko(b) @ "1d") est rejeté.
• Note de grammaire : le membre droit de @ est un opérande clock restreint, donc x @ "1d" + 1 s'analyse comme (x @ "1d") + 1.

Les clocks généralisent la « timeframe » — le traitement complet (échauffement, alignement, live()) est dans temps et état.

#Ranges : a..b

.. construit un range et n'existe que dans les positions de range — ce n'est pas un opérateur d'expression, ne peut pas être chaîné (non associatif), et n'entre jamais en collision avec la projection . ou les littéraux de nombre (2..200 se lexe comme 2 .. 200).

fluxbb = bollinger(close, 20)
fill bb.upper..bb.lower            // band between two price streams
len = input(14, 2..200)            // bounded parameter range

Les deux extrémités d'un fill doivent vivre sur le même axe scalaire ordonné — fill close..rsi(close, 14) est [ErrDim] (voir Inférence pour les règles d'admissibilité).

#Indexation et projection

La projection e.f lit un champ d'un record ([Proj]). Un champ manquant ou un récepteur non-record est [ErrField] — avec un correctif rapide vers le nom le plus proche :

fluxbb = bollinger(close, 20)          // record{upper, middle, lower : price}
plot bb.upper                      // price
bb.uper                            // ✗ [ErrField] — no such field; did you mean upper?

L'indexation v[i] sur un récepteur vec<κ>[n] lit un élément ([Index]). L'index peut être un ordinal d'exécution ; la capacité déclarée n garde l'opération totale, et les lectures hors bornes produisent na — jamais [ErrTotal], jamais un trap. C'est le substrat de l'idiome slotmap (collections bornées à handles stables et tombstones na).

Un nom pointé peut aussi être un nom qualifié plutôt qu'une projection — T.Ctor sélectionne un constructeur du variant déclaré T, et mod.f nomme une entrée d'un module importé. Les deux se résolvent pendant la résolution de noms, avant que [Proj] ne soit jamais considéré. Ce qui nous amène au troisième sens du point :

#UFCS : close.ema(20).rsi(14)

Uniform Function Call Syntax : recv.f(args) est exactement f(recv, args) — le récepteur devient le premier argument. C'est un désucrage sémantique sur l'arbre déjà analysé, pas une forme grammaticale, et c'est ce qui fait que les pipelines de gauche à droite se lisent dans le sens où coulent les données :

fluxsmooth = close.ema(20).rsi(14)                      // ≡ rsi(ema(close, 20), 14)
top5   = vec.topK(window(close, 100), (x) -> x, 5)  // a namespace call — the dot means something else here

Le point a trois sens, décidés à la compilation avec un token de lookahead :

1. recv.f sans ( — un champ de record (bb.upper), règle [Proj] ;
2. recv.f( où f se résout en une fonction — un appel UFCS, désucré en f(recv, …) ;
3. mod.f / T.Ctor où le côté gauche nomme un module ou un variant déclaré — un nom qualifié, résolu avant l'un ou l'autre des précédents.

Départage : si recv a un champ f et que f nomme une fonction, recv.f(…) est l'appel UFCS — un champ n'est jamais appelable, donc l'autre lecture ne pourrait être qu'une erreur.

Le piège est de lire (2) là où seul (3) s'applique. UFCS atteint les fonctions dans la portée — le prélude — et topK n'en fait pas partie : elle vit dans vec.*. Donc w.topK(…) n'est pas un appel UFCS mais une projection de champ sur un vecteur, ce qui est [ErrField]. Écrivez vec.topK(w, …). La règle empirique est celle que le menu de complétion impose déjà : si l'éditeur ne le propose pas après le point, ce n'est pas là.

Pourquoi cette règle existe. UFCS n'ajoute aucune grammaire et aucune sémantique — le vérificateur vérifie recv contre le premier paramètre de la fonction exactement comme si vous aviez écrit l'appel direct — mais il achète la découvrabilité : après close., l'éditeur peut proposer précisément les fonctions dont le premier paramètre accepte un price, filtrées par kind. Un seul mécanisme, des pipelines lisibles, une complétion consciente des kinds.

Les arguments nommés se composent avec lui : recv.f(x, mode: fast) lie mode par nom de paramètre et le vérifie comme un positionnel (voir Inférence).

#Mise à jour de record : e with { … }

with produit un record identique à e sauf pour les champs listés. Il est préservant de la forme ([With]) :

• chaque champ listé doit déjà exister — [ErrField] sinon (pas de création silencieuse de champ) ;
• chaque valeur doit se coercer vers le kind déclaré du champ — [ErrArg] sinon ;
• les champs non listés sont reportés inchangés, et le résultat a exactement le kind de e.

fluxvariant Phase { ask | suspense | revealed }
m  = { score: 0, phase: ask }
m2 = m with { score: m.score + 1, phase: revealed }
m with { scrore: 0 }        // ✗ [ErrField] — typo caught, nothing silently added

with est un suffixe postfixe (même palier que l'appel et la projection), donc il se chaîne : m with { a: 1 } with { b: 2 }.

Pourquoi cette règle existe. La mise à jour fonctionnelle sans with signifie reconstruire le record entier à la main — et un champ oublié est une perte d'état silencieuse. La préservation de la forme transforme cette classe de bug en [ErrField] à la compilation.

#Déstructuration : let {a, b} = e

Un motif de record à gauche d'une liaison extrait les champs par nom. Il est irréfutable — il ne peut jamais échouer à l'exécution, donc il est permis exactement là où aucun branchement n'est possible :

fluxw = let { upper, lower } = bollinger(close, 20) in upper - lower   // level — `let … in` is an EXPRESSION
{ macd, hist } = macd(close)                                       // a program-level bind destructures too

• un champ nommé qui n'existe pas, ou un sujet non-record, est [ErrField] ;
• si le sujet est na, chaque champ lié est na — l'absence s'écoule vers l'intérieur, de façon cohérente avec les règles de comparaison ;
• la déstructuration de variant est réfutable et vit donc dans match, dont le vérificateur impose l'exhaustivité ([ErrTotalMatch]) — un let ne branche jamais.

#La famille ? : ??, ?., ternaire

Trois morceaux de pur sucre, tous désucrés vers des constructions scellées — pas de nouveaux kinds, pas de nouvelle sémantique :

fluxm     = macd(close)                       // record{macd, signal, hist}
len   = close[1] ?? close                 // price — first bar handled
hist  = m?.hist ?? 0                      // safe-nav then default
side  = close > open ? 1 : -1             // ternary, right-associative

Parce que ?? est nz, il suit les règles de borne supérieure : des branches de dimensions différentes s'élargissent vers quantity (avec un avertissement), et mélanger des tags de représentation (f64 vs decimal) est [ErrRepr] — le sucre ne peut pas faire ce que la forme désucrée ne ferait pas.

#Le placeholder _

Au site d'argument d'un kernel d'ordre supérieur, un unique _ libre dénote l'unique paramètre d'un lambda implicite :

fluxscaled = window(close, 20).map(_ * 1.1)      // ≡ .map((x) -> x * 1.1)
present = vec.where(window(close, 20), (x) -> is_some(x))  // a namespaced HOF — write the lambda
window(close, 20).fold(0, _ + _)   // ✗ — two-parameter position: write (acc, x) -> acc + x

Le placeholder est confiné à un kernel du prélude atteint par UFCS, où le récepteur fixe l'unique paramètre ; un appel d'ordre supérieur avec namespace comme vec.where(…) prend un lambda explicite, car _ n'a aucun lieur auquel s'attacher là.

La règle est strictement mono-argument : exactement un _, dans une position attendant une fonction à un paramètre. Deux _ ou plus, ou un site à deux paramètres comme fold, sont rejetés avec une demande de lambda explicite — le sucre ne devine jamais quel _ est lequel. Le motif _ des bras de match est un symbole différent, distinct par sa position ; les deux n'entrent jamais en collision.

#Précédence et associativité

Du plus lâche au plus serré. La grammaire stratifiée normative — y compris pourquoi cette table n'a besoin d'aucune annotation de précédence — est dans grammar.md.

Hors de la cascade :

• .. — non associatif, licite uniquement dans les positions de range (fill a..b, input(n, lo..hi)) ;
• @ — son opérande droit est un opérande clock restreint, donc x @ "1d" + 1 est (x @ "1d") + 1 ;
• : et , — séparateurs, jamais opérateurs.

Chaque palier ne se réfère qu'au suivant, plus serré — pas de récursion croisée — ce qui rend toute la cascade non ambiguë par construction plutôt que par condition annexe.

#Voir aussi

• kinds.md — le treillis sur lequel ces opérateurs calculent : sortes, ⊤/⊥, arêtes de coercition, tags.
• inference.md — comment les kinds sont assignés, l'inférence de présentation, et le catalogue d'erreurs complet.
• grammar.md — la grammaire normative, les cinq lectures de la flèche unique, la désambiguïsation.
• time-and-state.md — flux, clocks, scan/fold/loop, causalité et échauffement en profondeur.
• asset-currency — le modèle complet de tag d'actif : places, toSource, money.
• compute — math.*/stat.* et les règles dimensionnelles de la bibliothèque numérique.

Inférence — kinds, présentation, et la politique d'erreurs

Kinds donne la relation : quels kinds existent et quels jugements tiennent. Cette page donne l'algorithme : comment un kind est effectivement assigné à chaque nœud d'un programme, comment la présentation d'un graphique — pane, échelle, guides, couleur, UI de paramètres — est dérivée de ces kinds plutôt que configurée, et ce qui se passe quand quelque chose ne type pas.

Trois propriétés rendent l'algorithme digne d'être spécifié précisément, plutôt que laissé comme un détail d'implémentation. Il est principal (le kind qu'il synthétise est le plus petit que le programme admet, il n'y a donc jamais de choix à faire), il est déterministe (le même source produit toujours les mêmes kinds, ce qui permet à deux moteurs d'émettre du code byte-identique), et il est total (chaque état d'édition, y compris une ligne à moitié saisie, reçoit un kind ou une erreur précise — jamais un échec silencieux).

#Deux modes

L'inférence est bidirectionnelle : elle lit les mêmes règles de typage dans deux directions.

La synthèse — Γ ⊢ e ⇒ κ — est le mode par défaut, ascendant. Elle produit le plus petit kind que l'expression admet. Les feuilles synthétisent leur kind exact (close ⇒ price, 14 ⇒ lit, "hi" ⇒ string) ; les introductions synthétisent leur structure (un littéral de record, une scène, un constructeur) ; les éliminations synthétisent en calculant — un appel, une projection, un match, un delay, un rééchantillonnage, et chaque nœud arithmétique, qui demande son kind résultat à l'algèbre dimensionnelle.

La vérification — Γ ⊢ e ⇐ κ — est le mode descendant, et elle ne s'exécute qu'aux sites de consommation, où un kind attendu existe déjà :

Cette dernière ligne est aussi ce qui désambiguïse la flèche : (x) -> x * 1.1 est un lambda exactement quand sa position attend une fonction, et une paire de tween sinon. La désambiguïsation est une conséquence du mode, pas une règle séparée (voir Grammaire).

#La subsomption est confinée

La règle de coercition — « un a peut être utilisé là où un b est attendu si a ≤ b » — se déclenche uniquement à la frontière entre les deux modes. Pour vérifier e ⇐ κ : synthétiser e ⇒ κ', puis exiger κ' ≤ κ. Silencieux si l'arête est ≤safe ; un avertissement avec un correctif rapide si elle est ≤lossy ; [ErrDim], [ErrArg] ou [ErrPlot] — selon la position — si κ' ⊀ κ.

La coercition ne se déclenche jamais pendant la synthèse. Un nœud n'est jamais élargi spontanément ; son kind synthétisé reste le plus bas connu.

Pourquoi le confinement est porteur. Supposez que la subsomption soit permise dans la synthèse. Alors x = close - close pourrait synthétiser level ou, par l'arête d'effacement avec perte, quantity. Les deux sont dérivables. Mais plot x lit le registre de présentation au kind : level donne un pane centré sur zéro, quantity donne un pane auto par défaut. Un seul programme, deux sorties valides, deux artefacts compilés différents — et la garantie que l'aperçu de l'éditeur correspond au module livré (I7) serait perdue. Le confinement est ce qui fait du « kind d'une expression » une fonction plutôt qu'un choix.

#Principalité

Avec la synthèse définie comme ci-dessus, chaque expression a un kind principal : l'unique plus petit kind qu'elle admet. La preuve est une induction d'une ligne — chaque feuille synthétise exactement, chaque nœud combine les kinds minimaux de ses enfants avec soit ⊔ soit l'algèbre dimensionnelle (les deux renvoyant un résultat unique, vérifié par énumération), et la seule règle d'élargissement est exclue du mode. Donc le kind synthétisé est le plus petit, et vérifier ≤ à chaque consommateur est alors complet.

Le cas multi-site. Un champ initialisé à na synthétise ⊥ à ce site — mais son kind n'y est pas coincé : le kind principal d'un champ de record est la borne supérieure sur tous ses sites de construction et d'affectation. Dans le plan APP, un champ de Model écrit picked: na dans init et picked: key (un string) dans un bras d'update a le kind string, na restant une valeur d'exécution licite de ce champ (⊥ ≤ string). Le point fixe converge en une passe car les kinds assignés ne dépendent jamais du record lui-même. Déclarer record Model { … } d'emblée est la même chose écrite explicitement.

#Terminaison et déterminisme

L'algorithme est une unique passe ascendante sur le graphe trié topologiquement. Il se termine parce que le treillis est fini par famille et de hauteur finie, le graphe est acyclique (la causalité le garantit), et ⊔, ⊓ et l'algèbre sont tous en O(1) — il n'y a aucune itération de point fixe et aucun stockage de variables d'unification nulle part.

Il est aussi confluent : le kind synthétisé d'un nœud ne dépend que des kinds de ses entrées, et ⊔ est commutatif et associatif, de sorte que le résultat est indépendant de l'ordre topologique choisi. L'inférence est donc une fonction déterministe du graphe — le même programme produit toujours les mêmes kinds, d'où le même module émis. C'est l'un des fondements de l'égalité byte-à-byte interpréteur ≡ WASM (voir Compilateur et runtime).

#Polymorphisme borné, résolu puis oublié

Le catalogue est plein de familles préservant le kind : ema, sma, sum, highest, change, stat.stdev — chacune écrite (src: α ≤ quantity, len: lit) → ρ(α). C'est le seul polymorphisme en v1, et il est délibérément peu profond.

À chaque site d'appel, α est résolu en un kind fermé et monomorphe : α := la borne supérieure des kinds synthétisés pour les arguments en positions α ; puis α ≤ quantity est vérifié ([ErrArg] sinon) ; puis le kind de retour est la forme de la famille instanciée à ce α. Pour les familles de différence, la forme est le δ dérivé de l'algèbre ± figée : δ(price) = level.

fluxa = ema(close, 20)              // α := price      ⇒ price
b = ema(rsi(close, 14), 9)      // α := osc(0,100) ⇒ osc(0,100)   — smoothing preserves the kind
c = change(close, 5)            // δ(price)        ⇒ level
d = change(rsi(close, 14), 5)   // δ(osc)          ⇒ osc, centred on 0

α est résolu puis oublié. Ce n'est pas une variable d'unification qui persiste à travers le programme, de sorte que deux sites ne peuvent jamais se contredire, et la propriété « pas d'unification générale » qui garde l'inférence en une seule passe survit intacte.

#Typer un programme inachevé

Un éditeur type un programme qui est en train d'être écrit, pas un programme fini — donc l'algorithme assigne un kind à chaque état d'édition.

Un nom non lié (vous êtes à mi-chemin de le saisir) et un trou de syntaxe (un nœud d'erreur d'analyse) synthétisent tous deux un trou de kind : un ⊤ contenu qui émet exactement un diagnostic ([ErrUnbound]) et n'empoisonne pas ses frères.

De là découle le cône typable : le plus grand sous-graphe dans lequel chaque nœud, et chaque entrée transitive de chaque nœud, est exempt de ⊤ et exempt de trous. L'aperçu en direct évalue exactement ce cône et rend le reste comme --. Une erreur locale ne vide donc jamais tout l'aperçu — un programme correct a un cône égal au graphe entier, et un programme avec un nom non lié prévisualise encore tout ce qui n'en dépend pas.

Le cône est un artefact strictement au moment de l'édition : un ⊤ dans une position consommée reste un échec dur pour émettre du code. La garantie de byte-identité est intacte.

#Re-typage incrémental

Lors d'une édition, seuls le nœud modifié et son cône aval de consommateurs de kind sont re-synthétisés ; le kind de chaque autre nœud est mémoïsé sous l'identité de nœud épinglée que le compilateur maintient déjà pour le hachage et l'élimination de sous-expressions communes. Parce que le graphe est acyclique et le treillis est monotone et fini, ceci converge en une passe descendante.

Le re-typage incrémental est observationnellement égal à une ré-inférence complète — c'est la même fonction, mémoïsée — de sorte qu'il ne peut jamais être en désaccord avec le module livré. C'est ce qui maintient le budget d'édition sous les 16 ms, avec l'analyse incrémentale.

#La présentation est inférée, pas configurée

Voici le fruit d'un système de kinds qui suit le sens. Un kind dit déjà ce qu'est une valeur ; il dit donc aussi comment elle devrait être montrée. C'est pourquoi le premier programme que quiconque écrit fait une ligne et n'a besoin d'aucune option :

Le compilateur dérive une entrée de registre à partir du kind, et l'affine avec des métadonnées de l'opération elle-même :

registry := merge( reg(kind), opMeta(expression) )

reg(kind) fournit les défauts ; opMeta les affine (un rsi ajoute ses guides 30/70). La table de défauts complète :

La classe CSS fait partie de la dérivation, pas d'un détail du thème : l'hôte l'appose sur la série rendue, de sorte qu'une feuille de style peut restyler chaque oscillateur du graphique sans qu'aucun script ne nomme une couleur. C'est le seul endroit où « la présentation est inférée » atteint jusqu'à la page.

Quatre règles complètent le tableau :

1. Overlay si et seulement si la valeur partage l'axe des prix. Sinon elle reçoit un pane.
2. Le co-tracé joint les échelles. Deux séries dans un même pane prennent la ⊔ de leurs bornes ; si cette borne supérieure atterrit sur quantity, vous obtenez [WarnBranchDim] et une suggestion de scinder le pane. (Un overlay price à côté d'un pane ratio n'est pas un mélange — ce sont deux panes, et cela n'avertit de rien.)
3. Le kind final décide. level + price → price, donc l'expression se met en overlay.
4. Les lignes de référence issues de la convention vivent dans opMeta, pas dans le kind. osc(0,100) donne une ligne médiane ; le fait que rsi marque conventionnellement 30 et 70 est une propriété de rsi.

Un record éclate en ses champs, chacun présenté à son propre kind — c'est pourquoi plot bollinger(close, 20, 2) produit trois lignes de prix plus une bande, et plot macd(close) produit un pane centré avec un histogramme et une ligne de signal, sans aucun code pour le dire.

#Surcharges — l'intention l'emporte sur le défaut

L'inférence donne le défaut ; l'auteur le surcharge dans le bloc plot, et parce que le système connaît le kind, la surcharge est intelligente plutôt qu'aveugle :

fluxm = macd(close)
plot m.macd { overlay }                  // a level FORCED onto the chart → it gets its OWN secondary axis
plot ema(close, 20) { pane }             // a price FORCED into a pane → auto-scaled, fine
plot m.hist { style: histogram, color: if m.hist > 0 then up else down }
plot rsi(close, 14) { guides: [20, 80] } // authored reference lines, kind-checked as level|osc

ich = ichimoku()                          // sourceless: it reads high/low/close itself
plot ich.chikou { offset: -26 }          // a DISPLAY shift: it moves the x position, never the value

L'UI de paramètres est dérivée de la même façon : un input(…) synthétise son kind, et le kind donne le widget (un champ numérique avec un range, un sélecteur de source, un booléen, une énumération), avec title:/group:/tooltip: comme métadonnées optionnelles. Un descripteur d'accessibilité est dérivé du kind également, de sorte qu'une série tracée est annoncée de façon significative sans que l'auteur n'écrive d'étiquette.

#Ce qui peut être présenté, tout court

L'admissibilité de présentation est un jugement comme un autre, décidé par kind, et énuméré exhaustivement :

Notez l'asymétrie délibérée : dir n'est pas traçable comme une ligne et pas ordonnable, mais il est compatible avec les marks et constitue un canal de coloration de barres licite. Ses seuls canaux de présentation sont les deux qui ont du sens pour une direction à trois valeurs.

Pourquoi énumérer plutôt qu'argumenter. Parce que le treillis est fini par famille, ces tables sont vérifiées par machine — chaque kind, et chaque paire de kinds, est passé par chaque jugement. « Aucun kind n'est laissé sans sémantique » n'est pas une affirmation dans un document ; c'est un test qui échoue quand cela cesse d'être vrai.

#La politique d'erreurs

Une erreur est dure si et seulement si une garantie porteuse est violée — causalité, totalité, le pare-feu — ou qu'une impossibilité dimensionnelle apparaît dans une position exigeante. Tout le reste qui n'est que suspect est un avertissement avec un correctif rapide.

#Erreurs dures

Le plan APP ajoute [ErrState] pour un champ de Model non borné, sur exactement ce motif ; voir Plan APP.

#Avertissements

#Ce qu'est un message d'erreur

Un diagnostic est humain, dimensionnel, actionnable, et lié — jamais une trace de pile :

price + osc — you are adding a price and a 0–100 oscillator.
  close + rsi(close, 14)
          ^^^^^^^^^^^^^^ osc(0,100), a dimensionless bounded value
  A point on the price axis and a dimensionless number have no common meaning.
  Did you mean  close + atr(14)  (a price + a displacement),
  or            close * norm(rsi(close, 14))  (scale the price by a fraction)?
  → kinds: the affine substrate

Un repaint refusé est expliqué, pas simplement interdit (« cela ferait changer une valeur passée une fois la barre close »), car le refus est la fonctionnalité.

Anti-cascade. Un nœud empoisonné se propage sans re-diagnostiquer : une seule faute racine produit exactement un message, et les nœuds en aval restent silencieux. Une seule faute de frappe ne produit pas quarante erreurs.

#na à l'exécution

Les kinds sont statiques ; na est l'histoire à l'exécution, et les deux sont conçus pour s'accorder.

• Toute comparaison touchant na produit na — jamais true, jamais false. L'absence est testée avec is_na(x) et la présence avec is_some(x), tous deux signal.
• nz(x, d) (et son sucre x ?? d) substitue une valeur par défaut ; max/min absorbent na point par point, tandis que les réducteurs de fenêtre le propagent (une fenêtre contenant un trou produit na, correspondant à l'oracle natif dont ils doivent rester byte-identiques).
• Un match sur un sujet possiblement na doit le couvrir — un bras na ou _.
• Déstructurer un record na donne na à chaque champ.
• Un NaN produit par l'arithmétique est na — le kind est préservé, et il est affiché comme un vide plutôt que comme un échec. La division par zéro n'est pas une erreur ; c'est une valeur absente.
• En interne, na est forcé à un unique motif de bits canonique à chaque frontière de stockage, de hachage et de sérialisation. Rien de cela n'est observable dans un programme — c'est ce qui fait que deux moteurs s'accordent sur les octets d'une valeur qui n'est pas là (Modèle mémoire).

#Voir aussi

• Kinds — le treillis, les sortes, les tags, les déclarations nommées.
• Opérateurs — l'algèbre dimensionnelle règle par règle.
• Grammaire — comment les modes d'inférence résolvent la flèche et les têtes de conteneur.
• Temps et état — causalité, échauffement, live() et le pare-feu en pratique.
• L'éditeur — complétion filtrée par kind, cartes au survol, le cône typable dans l'aperçu en direct.
• Compilateur et runtime — pourquoi l'inférence déterministe est un prérequis à la byte-identité.

Temps et état

Cette page spécifie le modèle temporel du plan ANALYSIS : ce qu'est un flux, comment on accède au passé, pourquoi on ne peut pas accéder au futur, comment s'écrivent l'état borné et l'itération, et comment l'axe des pas d'une série — son horloge — est lui-même une valeur de première classe. Tout le reste de Flux s'appuie sur les garanties définies ici : causalité (une valeur ne dépend que du passé), no-repaint (une valeur, une fois produite pour un pas, ne change jamais), totalité (chaque construction se termine dans une borne connue à la compilation) et byte-identité (le même programme produit les mêmes octets sur chaque moteur, warm-up compris).

Les kinds (price, level, signal, …) sont spécifiés dans kinds.md ; cette page les emploie librement et en annote ses exemples. Les horloges côté présentation — frames et événements — relèvent de canvas.md et app-plane.md ; ici, l'horloge est l'horloge des données, celle sur laquelle avancent les valeurs d'analyse.

#Tout est un flux

Une valeur du plan ANALYSIS est un flux : une valeur au fil des pas. close n'est pas un nombre ; c'est l'historique entier des valeurs de clôture, une par pas de l'horloge du graphique. Une constante est un flux dégénéré — la même valeur à chaque pas. Dans la spécialisation graphique, un pas est une barre ; rien dans le modèle ne dépend de cette lecture.

L'arithmétique est élément par élément : une expression relie des flux entiers, et le résultat est de nouveau un flux.

fluxfast   = ema(close, 12)      // price — a stream: one value per step
slow   = ema(close, 26)      // price
spread = fast - slow         // level — element-wise: spread at step t = fast[t] - slow[t]

Il n'y a aucun indice à gérer et aucune boucle à écrire : vous énoncez la relation une fois, et elle tient à chaque pas. Sous le capot, le runtime est incrémental — quand un nouveau pas arrive, chaque nœud avance d'un cran, en réutilisant son propre état borné ; rien n'est recalculé depuis le début. La lecture élément par élément (historiques entiers) et la lecture incrémentale (un pas à la fois) décrivent le même programme ; le compilateur vous doit leur équivalence.

Pourquoi cette règle existe. Les flux sans indices sont ce qui rend possible le reste de la page. Parce qu'un programme ne nomme jamais de positions, il ne peut nommer une position future ; parce que chaque opérateur avance pas à pas avec un état borné, la totalité et les bornes mémoire sont des propriétés du langage, non de la discipline de l'auteur.

#L'opérateur de délai x[n]

La seule façon d'atteindre le passé est le délai postfixe x[n] : la valeur qu'avait le flux x il y a n pas.

fluxprev = close[1]              // price — the previous step's close; na on the first step
diff = close - close[1]      // price − price → level : the one-step change
up4  = close > close[4]      // signal — na on the first four steps (comparison propagates na)

Règles :

• n est une constante const-foldée, n ≥ 0 — un littéral, ou un paramètre dont la plage bornée permet au compilateur de réserver le pire cas. Le délai, c'est de la mémoire ; la mémoire est bornée à la compilation.
• Avant le pas n, x[n] vaut na — le passé qui n'existe pas encore (voir Warm-up et na).
• Sur un vec, le même postfixe [i] est une lecture d'élément bornée, non un délai ; le kind de l'opérande lève l'ambiguïté.

Un délai dépendant des données est rejeté : le retard serait non borné.

fluxk = barssince(close cross_up open)
close[k]                     // ✗ [ErrTotal] — the lag must be a compile-time constant

#Il n'y a pas d'indice négatif

x[-1] — « la valeur suivante » — n'existe pas. Ni comme forme déconseillée, ni comme lint qu'un auteur déterminé pourrait faire taire : cette forme n'existe pas. L'indice de délai est non négatif par la définition même du langage, et toute tentative d'en écrire un négatif est rejetée.

fluxclose[-1]                    // ✗ [ErrCausal] — the future is not addressable

Pourquoi cette règle existe. La causalité est une propriété de compilation, non une règle de style. Dans un langage où x[-1] s'analyse et se contente d'un avertissement, chaque garantie en aval — rejouabilité, fiabilité des alertes, ré-exécution byte-identique — ne tient que pour les scripts bien élevés. Flux inverse le fardeau : le script mal élevé est inexprimable, si bien que les garanties tiennent pour tout programme qui compile.

#La causalité est un théorème

Parce que le passé n'est atteignable qu'à travers un délai borné et non négatif, et que l'unité en formation de toute horloge est illisible (voir @ — l'éliminateur d'horloge), tout programme ANALYSIS satisfait, par construction :

output[t] = f(inputs[0..t])

La valeur au pas t est une fonction des entrées jusqu'au pas t inclus — jamais de quoi que ce soit de plus tardif. Deux conséquences en découlent.

Tout cycle de rétroaction franchit un délai d'une unité. Une définition peut dépendre de sa propre valeur précédente (c'est cela, un état courant), mais jamais de sa propre valeur courante — un cycle sans délai n'a aucune lecture causale et est rejeté :

fluxema20 = 0.1 * close + 0.9 * ema20                       // ✗ [ErrCausal] — cycle with no unit delay
ema20 = scan(close, (prev) -> 0.1 * close + 0.9 * prev) // ✓ the delay is built into scan

scan (ci-dessous) est la manière sanctionnée de refermer une boucle de rétroaction : le combinateur vous remet la sortie du pas précédent, si bien que le délai d'une unité fait partie de son sens plutôt que d'être quelque chose que vous devez penser à insérer.

No-repaint. Puisque output[t] ne dépend que de inputs[0..t], et que les entrées sont en ajout seul (append-only), une valeur une fois produite ne peut jamais être contredite par des données ultérieures. C'est la garantie no-repaint : une valeur, une fois produite pour un pas, ne change jamais. L'historique est immuable — le graphique auquel vous revenez en défilant est exactement celui qui a été calculé en direct, l'alerte qui s'est déclenchée est exactement celle qu'une ré-exécution déclenche. Le repaint n'est pas « détecté » ni « signalé » ; il est absent du vocabulaire. Toute la famille des rejets partage un seul diagnostic : [ErrCausal] — délai négatif, rééchantillonnage non causal, cycle de rétroaction sans délai d'unité, retard non borné.

#Warm-up et na

La plupart des noyaux ont besoin d'historique avant de pouvoir répondre : un RSI à 14 pas n'a rien d'honnête à dire au pas 3. Jusqu'à ce qu'assez de données soient arrivées, la sortie d'un noyau est na — la valeur absente. C'est son warm-up naturel, et chaque noyau hérite exactement du warm-up de sa définition ; le langage n'impose par-dessus aucune politique globale de « na jusqu'à N ». La byte-identité tient dès le tout premier pas : un noyau Flux et l'implémentation native du même noyau chez l'hôte s'accordent sur chaque octet, warm-up compris (invariant I6).

na habite chaque kind (na : ∀κ.κ) et se propage à travers l'arithmétique avec le kind préservé. Sa sémantique de comparaison est stricte :

• Toute comparaison impliquant na — na == x, na < x, même na == na — vaut na, jamais true ni false. On ne peut pas tester l'absence avec ==.
• L'absence se teste avec is_na(x) → signal ; la présence avec son dual is_some(x) = not is_na(x) → signal.
• Un match sur une valeur possiblement na doit la couvrir (un bras na ou _), sans quoi le match est rejeté comme non exhaustif.
• Déstructurer un record absent (let {upper, lower} = bb quand bb vaut na) donne na dans chaque champ.

fluxr     = rsi(close, 14)       // osc(0,100) — na on steps 0..13
warm  = is_na(r)             // signal — 1 during warm-up
bad   = r == na              // na, always — never true; use is_na
assert r <= 100              // passes from step 0: na <= 100 is na, and an na verdict is PASS

Le verdict d'assert sur na est délibérément pass : une assertion ne se déclenche que sur un signal définitivement faux, si bien que le warm-up ne peut produire de faux échecs. Là où l'absence elle-même doit échouer, écrivez assert is_some(r) and r <= 100.

La substitution d'une valeur par défaut utilise nz(x, d), ou sa forme opérateur x ?? d (c'est la même construction) :

fluxo  = nz(obv(), 0)            // volume — 0 is a literal and adopts the slot's kind
f  = close ?? sma(close, 5)  // price — x ?? d ≡ nz(x, d); right-associative

Les deux opérandes doivent s'accorder dimensionnellement (le kind du résultat est leur borne supérieure) ; même dimension avec des tags de représentation différents — f64 contre decimal, temps machine contre temps calendaire — est [ErrRepr], réclamant une conversion explicite.

Absorption vs propagation. L'arithmétique propage na. Trois opérateurs point à point l'absorbent au contraire — math.max, math.min, nz — si bien que math.max(x, na) = x : une opérande manquante n'empoisonne pas un extrême courant. Les réducteurs de fenêtre n'héritent pas de cette absorption : highest(x, 20) sur une fenêtre contenant un trou donne na, exactement comme sma, sum et stdev. L'asymétrie est fixée par la byte-identité aux noyaux de l'hôte : les réducteurs de fenêtre suivent l'oracle natif, et un fold écrit à la main avec max (qui saute na par absorption) est un programme différent — légitime — et non une orthographe plus rapide de highest.

Une note de représentation : na est un unique motif de bits épinglé à chaque frontière de stockage et de hachage, pour que la byte-identité et la vérification du rejeu tiennent à travers les moteurs ; la sémantique ci-dessus n'en est pas affectée. Les détails vivent dans internals/compiler-and-runtime.md.

#Fenêtres et itération bornée

window(x, n) matérialise les n dernières valeurs d'un flux sous forme de vecteur :

fluxw = window(close, 20)        // vec(price, 20) — the last 20 closes, at every step

La capacité n est const-foldée — un littéral, ou un input de plage bornée (le compilateur réserve le pire cas). Une capacité non constante ou surdimensionnée est rejetée :

fluxlen = barssince(close cross_up open)
window(close, len)           // ✗ [ErrTotal] — capacity must be a compile-time constant

fold et map sur une fenêtre sont la boucle for totale : ils visitent exactement la capacité de la fenêtre, pas davantage, et se terminent par construction.

fluxw    = window(close, 20)
hi   = w.fold(na, (acc, x) -> math.max(acc, x))   // price — max absorbs na during warm-up
devs = w.map((x) -> x - sma(close, 20))      // vec(level, 20) — element-wise, kind-tracked

#Pourquoi il n'y a pas de filter (ni de flatMap)

fluxw.filter((x) -> x > 0)       // ✗ — there is no filter: the result length would depend on data

La longueur de sortie d'un filtre dépend des données ; un flatMap multiplie les longueurs par un facteur dépendant des données. Ni l'un ni l'autre n'a de capacité à la compilation, et c'est la capacité qui porte les garanties de totalité et de mémoire — chaque collection dans Flux est un vec<κ>[n] dont le n est une borne que le compilateur peut imputer à son budget. La sélection ne rétrécit donc jamais ; elle masque :

• vec.where(v, pred) — même longueur, na là où l'élément échoue au prédicat ;
• vec.mask(v, live) — même longueur, na là où le vecteur signal parallèle vaut 0.

fluxw     = window(close, 50)                          // vec<price>[50]
above = vec.where(w, (x) -> x > sma(close, 50))    // vec<price>[50] — na holes, no shrinking

Les vecteurs masqués se composent avec l'itération sensible aux na : un élément na ne produit rien. Les folds et les réducteurs voient le trou et appliquent leur propre politique na ; la compréhension de vue/canvas le saute purement et simplement — un élément masqué ne dessine aucun enfant :

fluxgroup { for lvl in window(close, 5) -> dot { at:(bar.i, lvl) } }   // na elements: no dot

Pourquoi cette règle existe. « Mémoire bornée » n'est un théorème que si aucune opération ne peut faire croître une collection au-delà de sa capacité déclarée ni rendre sa taille une surprise d'exécution. Les masques gardent la forme statique et déplacent la question « combien ont survécu ? » dans les valeurs (trous na, un count là où il en faut un) — ce qui est précisément l'information qu'un programme total peut transporter.

#État courant : scan

scan(seed, (prev) -> e) est l'accumulateur courant — la construction de rétroaction du langage. Au premier pas, prev est la graine (évaluée à ce pas) ; à chaque pas ultérieur, prev est la valeur que le scan lui-même a produite au pas précédent. La valeur émise est l'état. Le délai d'une unité qu'exige la causalité est à l'intérieur du combinateur : prev a toujours un pas de retard, si bien qu'un scan ne peut jamais lire sa propre sortie courante.

L'exemple canonique — une moyenne mobile exponentielle construite à partir des principes premiers :

fluxdef ema0(s, n) =
  let a = 2 / (n + 1) in
  scan(s, (prev) -> a * s + (1 - a) * prev)   // α → α : Σλ=1 affine step, kind-preserving

Un extrême courant tient en une ligne :

fluxpeak = scan(high, (prev) -> math.max(prev, high))  // price — running maximum since the first step

#État composite : une graine record

L'état reste rarement scalaire. Amorcez un scan avec un record et c'est le record entier qui est l'accumulateur ; le système de kinds suit chaque champ.

fluxdd = scan({ peak: close, draw: 0 }, (prev) ->
  let p = math.max(prev.peak, close) in
  { peak: p, draw: (p - close) / p })         // record{peak: price, draw: ratio}
plot dd.draw                                  // (p − close) : level ; level ÷ price → ratio

Un trailing-stop avec bascule — la famille SuperTrend — est un record d'un price et d'un dir ({-1, 0, +1}, comparé avec ==, jamais matché) :

fluxdef flip(mult) =
  let band = mult * atr(14) in                // num × level → level
  scan({ stop: close - band, side: 1 }, (prev) ->
    if prev.side == 1 then
      if close < prev.stop then { stop: close + band, side: -1 }
      else { stop: math.max(prev.stop, close - band), side: 1 }     // ratchet: never loosens
    else
      if close > prev.stop then { stop: close - band, side: 1 }
      else { stop: math.min(prev.stop, close + band), side: -1 })

#Machines à états : une graine variant et match

Quand l'état est un mode, amorcez le scan avec un variant et faites-le avancer avec match — l'éliminateur force le traitement de chaque mode ([ErrTotalMatch] sinon), si bien qu'une machine à états ne peut pas oublier silencieusement un cas :

fluxvariant Phase { Flat | Long(entry: price) }

def step(prev) = match prev {
  Flat    -> if close cross_up ema(close, 50) then Phase.Long(entry: close) else Phase.Flat
  Long(e) -> if (e - close) / e > 0.05 then Phase.Flat else prev
}

pos = scan(Phase.Flat, (prev) -> step(prev))

Regardez la règle de sortie, car c'est le système de kinds qui l'a écrite. Le premier jet évident est close < e * 0.95 — et il est rejeté : e est un price, un point affine, et mettre un point à l'échelle par un scalaire n'a aucun sens (5 % du « 42ᵉ parallèle » n'est pas un lieu). L'algèbre efface la dimension, et comparer le résultat à un price est [ErrDim]. Ce que vous vouliez réellement dire est un déplacement mesuré par rapport à l'entrée — (e - close) / e, un price − price sur un price, ce qui est un ratio, et un ratio se compare volontiers à 0.05. Le compilateur n'a pas simplement refusé le premier jet : il a nommé le second.

#Esquisse détaillée : une colonne point-and-figure

Les représentations pilotées par le prix maintiennent un état de colonne : dans quel sens la colonne court, son extrême courant, combien de boîtes elle a remplies. En tant qu'état de scan :

flux// state : record{ dir: dir, extreme: price, count: num }
def pnfCol(box, rev) =                        // box : level (const-folded), rev : num
  scan({ dir: 1, extreme: close, count: 0 }, (prev) ->
    if prev.dir == 1 and close >= prev.extreme + box then
      prev with { extreme: prev.extreme + box, count: prev.count + 1 }
    else if prev.dir == 1 and close <= prev.extreme - rev * box then
      { dir: -1, extreme: prev.extreme - rev * box, count: rev }
    else prev)                                // sketch: up-side only, one box per step

Les kinds sont tout l'intérêt de l'esquisse. count est un pur nombre de boîtes — sans dimension — tandis que box : level porte la dimension de prix. Donc :

• count * box : level — un nombre de boîtes fois une hauteur de boîte est un déplacement ;
• extreme + count * box : price — ancrer ce déplacement à l'extrême de la colonne redonne un point sur l'axe des prix.

Stockez count : num et l'algèbre reconstruit chaque quantité géométrique avec le bon kind ; stockez un prix par boîte et l'arithmétique se typerait comme un non-sens (price + price n'a aucun sens affine). La version de production de cette esquisse n'est pas du tout un scan mais un changement d'horloge — pnf(box, rev) dans Horloges — et pourtant son état interne se type par exactement ce raisonnement.

#stateful — l'échappatoire de bas niveau

stateful(seed, (st, bar) -> e) expose directement la primitive récursive du moteur : vous recevez l'état précédent et les données brutes du pas courant, et vous renvoyez l'état suivant. C'est la même construction que scan, le sucre syntaxique en moins, pour le rare noyau dont le pas ne peut se formuler comme une expression sur des flux nommés. Préférez scan ; recourez à stateful quand vous avez besoin du record de barre entier d'un coup.

fluxacc = stateful({ n: 0, ups: 0 }, (st, bar) ->        // seed is a RECORD; bar is the whole step
  { n: st.n + 1, ups: st.ups + (if bar.close > bar.open then 1 else 0) })

#loop — itération bornée au sein d'un pas

loop(max, init, step) itère au sein d'un seul pas : max tours (const-foldé), en partant de init et en appliquant step à la valeur courante. C'est le remplacement total d'un while : la borne fait partie du programme, si bien que la terminaison est un fait, non un espoir. Les chercheurs de racines, les solveurs de valeur implicite et les passes de lissage en sont les usagers naturels.

fluxdef nroot(x) =                                // num → num : Newton, a fixed 24 rounds
  loop(24, x / 2, (g) -> (g + x / g) / 2)

plot nroot(rsi(close, 14))                    // dimensionless in, dimensionless out

La totalité vient de max, et de max seul. C'est un plafond statique : le compilateur budgète le pire cas, si bien que le coût d'un pas est connu avant que le pas ne s'exécute, quoi que fassent les données. Sous cette forme livrée, le plafond est aussi le compte exact — loop exécute max tours et prend la dernière valeur — ce qui, en pratique, ne coûte rien ici, car Newton double ses chiffres corrects à chaque tour : une racine f64 a convergé bien avant le tour 24, et les tours restants sont des points fixes.

Post-v1. Le design scellé porte un quatrième argument, un prédicat de sortie anticipée : loop(max, init, step, until) s'arrête dès que until tient. Cela n'affaiblit pas la totalité — le budget reste max, et le compilateur le réserve toujours — cela laisse seulement une itération convergée cesser de payer pour des tours dont elle n'a pas besoin. La signature livrée ne le prend pas encore, si bien que la forme ci-dessus est celle qui s'exécute aujourd'hui.

Aucune boucle non bornée n'existe dans la surface v1 : il n'y a aucun jeton pour cela, et chaque noyau itératif pratique énonce son budget. (Open decision. Le design discute d'une échappatoire unsafe optionnelle pour une boucle non bornée et la déconseille par défaut ; rien dans le catalogue n'en a besoin.)

#Flux cumulatifs et ancrés

Deux combinateurs couvrent « depuis toujours » et « depuis un événement » :

• cum(x) → α — la somme expansive depuis le premier pas (un scan déguisé) ;
• cumSince(reset, x) → α — la même accumulation, réinitialisée à chaque front montant du reset : signal.

fluxtotal = cum(volume)                                        // volume — since the first step
sess  = in_session("09:30-16:00 America/New_York")         // signal — 1 while the session is open
sVol  = cumSince(sess, volume)                             // volume — since the session opened

Le VWAP ancré est cet idiome appliqué à un ratio d'accumulations — et il se type parce que l'algèbre dimensionnelle divise les dimensions l'une par l'autre :

fluxsess  = in_session("09:30-16:00 America/New_York")                // signal — the anchor
avwap = cumSince(sess, close * volume) / cumSince(sess, volume)   // pv ÷ volume → price
avwap = vwap(anchor: sess)                                        // the packaged overload

N'importe quel signal peut ancrer : une ouverture de session, un croisement, une rupture structurelle. Un input de kind price ou time peut être placé par clic sur le graphique — l'hôte réécrit la valeur choisie comme entrée épinglée, si bien que l'analyse lit toujours une entrée, jamais le pointeur, et un « VWAP depuis le pas où j'ai cliqué » reste pleinement causal et rejouable.

#Horloges : l'axe des pas est une valeur

Chaque série avance sur une horloge, et clock est un kind de première classe : un indice de pas ordinal plus une correspondance entre indices de pas et temps. Une horloge répond à deux questions — quel est l'horodatage du pas i ? et quel pas contient le temps t ? — et rien d'autre ; la position sur l'axe est toujours l'indice ordinal, jamais le temps mural.

Quatre constructeurs bâtissent des horloges :

Les horloges à grain temporel grossier et les horloges pilotées par le prix sont le même concept : une règle indiquant quand une unité se clôture. C'est pourquoi les représentations graphiques alternatives ne sont pas des moteurs de rendu greffés sur des données de barres — une série Renko ou point-and-figure est la machinerie de série ordinaire tournant sur une horloge différente — et pourquoi l'analyse multi-résolution n'est pas une fonctionnalité spéciale : une expression à une autre résolution est une expression sur une autre horloge, rééchantillonnée en retour (section suivante).

Les horloges sont des valeurs ordinaires. Elles circulent à travers if, à travers les paramètres de def, à travers input :

fluxregime = adx(14).adx > 25                     // signal — a trending regime
c      = if regime then tf("1d") else tf("4h") // clock — chosen like any other value

Les paramètres de constructeur se const-foldent : renko(50) (le littéral adopte le kind level), ou un input borné. Une boîte dépendante des données est rejetée — une horloge est un axe fixe, non une quantité qui dérive avec les données qu'elle est censée indexer.

Les fonctions peuvent consommer des horloges comme n'importe quelle valeur : barsPerYear(clk) → num dérive le nombre de périodes par an d'une horloge de temps (pour l'annualisation) ; sur une horloge d'événements (renko, pnf), la question n'a pas de réponse et elle renvoie na avec un diagnostic.