Il y a un moment que tout concepteur de langage \u00e0 pile redoute. Vous ouvrez un script \u00e9crit trois semaines plus t\u00f4t, et il ressemble \u00e0 \u00e7a :<\/p>\n\n\n\n
code size 'code_len' STO 0 @code_len 1 - 'i' {\"_\" code @i 1 sub char-> ->str + ->key} FOR<\/pre>\n\n\n\n<\/p>\n\n\n\n
Parfaitement valide. Parfaitement ex\u00e9cutable. Compl\u00e8tement illisible.<\/p>\n\n\n\n
C’est la tension classique des langages RPN : le paradigme est \u00e9l\u00e9gant et coh\u00e9rent \u00e0 l’ex\u00e9cution, mais na\u00efvement \u00e9crit, il devient du code en \u00e9criture seule \u2014 m\u00eame pour son propre auteur. MOGWAI<\/a> r\u00e9pond \u00e0 ce probl\u00e8me frontalement avec une couche de sucre syntaxique qui rend les scripts lisibles sans compromettre la puret\u00e9 du mod\u00e8le d’ex\u00e9cution sous-jacent.<\/p>\n\n\n\nDeux mondes, un seul langage<\/h2>\n\n\n\n
MOGWAI<\/a> est, dans son essence, un langage \u00e0 pile RPN. Chaque op\u00e9ration consomme des valeurs depuis la pile et y repousse ses r\u00e9sultats. Fonctions, structures de contr\u00f4le, affectations \u2014 tout ob\u00e9it \u00e0 la m\u00eame r\u00e8gle : poser les arguments d’abord, puis appeler le mot qui les traite.<\/p>\n\n\n\nMais MOGWAI<\/a> dispose aussi d’un parser, et ce parser sait traduire une syntaxe de surface plus lisible vers la forme RPN canonique que le runtime ex\u00e9cute r\u00e9ellement. Ce sont deux couches distinctes, et comprendre la fronti\u00e8re entre elles est la cl\u00e9 pour comprendre le langage.<\/p>\n\n\n\nPassons en revue les principales transformations.<\/p>\n\n\n\n
D\u00e9finir une fonction<\/h2>\n\n\n\n
Dans la forme source, une d\u00e9finition de fonction ressemble \u00e0 ceci :<\/p>\n\n\n\n
to 'greet' with [name: .string] do
{
\"Hello, \" @name + ??
}<\/pre>\n\n\n\n<\/p>\n\n\n\n
C’est lisible. On voit imm\u00e9diatement que greet<\/code> prend un param\u00e8tre cha\u00eene appel\u00e9 name<\/code>, et que son corps concat\u00e8ne un message de salutation et l’affiche. Apr\u00e8s parsing, le m\u00eame code devient :<\/p>\n\n\n\n\u00ab[name: .string] ->safeVars \"Hello, \" @name + ??\u00bb 'greet' DEFUNC<\/pre>\n\n\n\n<\/p>\n\n\n\n
Le sucre to ... with ... do<\/code> a disparu. \u00c0 sa place : un objet programme \u00ab \u00bb<\/code>, suivi du nom de la fonction et du mot DEFUNC<\/code>. DEFUNC<\/code> consomme les deux depuis la pile et enregistre la fonction.<\/p>\n\n\n\nL’instruction ->safeVars<\/code>, ins\u00e9r\u00e9e automatiquement par le parser juste apr\u00e8s le record de param\u00e8tres, n’est pas de la simple plomberie. C’est le mot qui valide et lie les arguments entrants selon la signature d\u00e9clar\u00e9e \u2014 ici, en v\u00e9rifiant que name<\/code> est bien un .string<\/code>. Sans elle, le record [name: .string]<\/code> ne serait qu’une valeur d\u00e9corative pos\u00e9e sur la pile sans aucun effet. C’est ->safeVars<\/code> qui rend la d\u00e9claration de param\u00e8tres r\u00e9ellement effective : la v\u00e9rification de type se produit \u00e0 l’appel, pas au parsing, et tout \u00e9cart est intercept\u00e9 avant m\u00eame que le corps de la fonction commence \u00e0 s’ex\u00e9cuter.<\/p>\n\n\n\nRemarquez les d\u00e9limiteurs \u00ab \u00bb<\/code> \u2014 un h\u00e9ritage direct des calculatrices RPL de HP. Ce ne sont pas de simples crochets d\u00e9coratifs. Un bloc \u00ab \u00bb<\/code> cr\u00e9e son propre scope de variables locales : les variables d\u00e9finies \u00e0 l’int\u00e9rieur ne peuvent pas s’en \u00e9chapper, et la fonction d\u00e9marre dans un environnement propre \u00e0 chaque appel. C’est fondamentalement diff\u00e9rent d’un simple bloc { }<\/code>, qui ne cr\u00e9e pas de nouveau scope et partage le contexte de variables de son appelant. La distinction est importante : les blocs { }<\/code> sont des quotations \u2014 des valeurs que l’on peut manipuler, stocker dans un dictionnaire ou passer \u00e0 une structure de contr\u00f4le. Les blocs \u00ab \u00bb<\/code> sont des programmes \u2014 des contextes d’ex\u00e9cution isol\u00e9s.<\/p>\n\n\n\nAffecter des variables<\/h2>\n\n\n\n
La forme source utilise l’op\u00e9rateur fl\u00e8che :<\/p>\n\n\n\n
now -> 'begin'
code size -> 'code_len'<\/pre>\n\n\n\n<\/p>\n\n\n\n
Apr\u00e8s parsing :<\/p>\n\n\n\n
now 'begin' STO
code size 'code_len' STO<\/pre>\n\n\n\n<\/p>\n\n\n\n
L’op\u00e9rateur -><\/code> est du sucre pur pour STO<\/code>. Le parser inverse simplement l’ordre \u2014 dans la source, la valeur vient en premier, puis la fl\u00e8che, puis le nom de la variable. Dans la forme canonique, la valeur et le nom sont tous deux sur la pile avant que STO<\/code> soit appel\u00e9. M\u00eame s\u00e9mantique, lisibilit\u00e9 diff\u00e9rente.<\/p>\n\n\n\nLes structures de contr\u00f4le<\/h2>\n\n\n\n
C’est l\u00e0 que le sucre justifie le plus sa pr\u00e9sence.<\/p>\n\n\n\n
La boucle while<\/code><\/h3>\n\n\n\nForme source :<\/p>\n\n\n\n
while (@code_ptr @code_len <) do
{
&dispatch @code_ptr get eval
'code_ptr' ++
}<\/pre>\n\n\n\n<\/p>\n\n\n\n
Forme canonique :<\/p>\n\n\n\n
{@code_ptr @code_len <}
{&dispatch @code_ptr get eval 'code_ptr' ++}
WHILE<\/pre>\n\n\n\n<\/p>\n\n\n\n
La syntaxe while ... do { }<\/code> encadre la condition et le corps dans des blocs explicites et lisibles. Apr\u00e8s parsing, les deux deviennent des quotations sur la pile, et WHILE<\/code> les consomme. Le runtime \u00e9value la quotation de condition de mani\u00e8re r\u00e9p\u00e9t\u00e9e ; tant qu’elle laisse une valeur vraie sur la pile, il \u00e9value la quotation du corps.<\/p>\n\n\n\nLe conditionnel if<\/code><\/h3>\n\n\n\nForme source :<\/p>\n\n\n\n
if (@cell_ptr 0 >) then
{
'cell_ptr' --
}<\/pre>\n\n\n\n<\/p>\n\n\n\n
Forme canonique :<\/p>\n\n\n\n
{! @cell_ptr 0 >}
{'cell_ptr' --}
IF<\/pre>\n\n\n\n<\/p>\n\n\n\n
Il y a quelque chose de subtil ici : le !<\/code> en d\u00e9but de bloc de condition. Ce marqueur indique au runtime d’auto-\u00e9valuer<\/em> le bloc plut\u00f4t que de simplement le poser sur la pile comme une quotation. Sans lui, {@cell_ptr 0 >}<\/code> resterait sur la pile comme une valeur, et il faudrait appeler eval<\/code> explicitement ensuite. Avec !<\/code>, le bloc s’auto-\u00e9value au moment o\u00f9 il est rencontr\u00e9, produisant le r\u00e9sultat bool\u00e9en qu’IF<\/code> attend. C’est un token minuscule avec un r\u00f4le pr\u00e9cis : il condense le pattern poser-puis-\u00e9valuer en une seule \u00e9tape.<\/p>\n\n\n\nLa boucle for<\/code><\/h3>\n\n\n\nForme source :<\/p>\n\n\n\n
0 @code_len 1 - for 'i' do
{
\"_\" code @i 1 sub char-> ->str + ->key
}<\/pre>\n\n\n\n<\/p>\n\n\n\n
Forme canonique :<\/p>\n\n\n\n
0 @code_len 1 - 'i'
{\"_\" code @i 1 sub char-> ->str + ->key}
FOR<\/pre>\n\n\n\n<\/p>\n\n\n\n
Les bornes de la boucle (0<\/code> \u00e0 @code_len 1 -<\/code>) et le nom de la variable d’it\u00e9ration ('i'<\/code>) sont pouss\u00e9s sur la pile, suivis de la quotation du corps, suivie de FOR<\/code>. Propre et m\u00e9canique.<\/p>\n\n\n\nCe qui dispara\u00eet au passage<\/h2>\n\n\n\n
La forme canonique rend une chose \u00e9vidente : les commentaires et les espaces disparaissent compl\u00e8tement. Le r\u00e9sultat du parsing est un flux de tokens plat et lin\u00e9aire \u2014 pas d’indentation, pas de lignes vides, pas de # explications<\/code>. Le runtime n’en a pas besoin. C’est quelque chose \u00e0 garder \u00e0 l’esprit quand on \u00e9crit du MOGWAI<\/a> : le fichier source est pour les humains, la forme pars\u00e9e est pour la machine, et le parser est le traducteur entre les deux.<\/p>\n\n\n\nQuelques exemples…<\/h2>\n\n\n\n\n\n\n