Principes de conception

SOML, acronyme de Sindre's Objectively Marvelous Language, se présente comme un format de configuration destiné aux humains. Le projet indique que le format évite les accolades au niveau supérieur, que les clés n'exigent pas de guillemets même lorsqu'elles contiennent des tirets, et que les sauts de ligne remplacent les virgules. La spécification repose sur une règle unique : le type d’une valeur est déterminé par sa syntaxe, jamais par son contenu. Ainsi, '123' reste une chaîne et 123 un entier. Le format propose également une forme canonique où deux valeurs identiques produisent exactement les mêmes octets, ce qui facilite le hachage et la signature. Le dépôt GitHub mentionne un suite de conformité contenant près de mille cas de test, garantissant que chaque implémentation lit un même fichier de façon identique.

Mécanismes de typage et de syntaxe

Les éléments syntaxiques sont explicitement définis. Les commentaires peuvent être introduits avec # ou avec le bloc /* … */, et ils sont autorisés partout où un espace blanc est accepté. Les chaînes littérales utilisent des apostrophes ('…') et ne nécessitent aucun échappement, ce qui rend les chemins Windows ('C:\Users\sindre\dev') et les expressions régulières ('^\d{4}-\d{2}-\d{2}$') triviales à écrire. Les chaînes multilignes sont encadrées par trois apostrophes et sont décalées automatiquement : le texte interne conserve les sauts de ligne mais perd l'indentation de la clôture. Les dates (2026-09-19), les instants (2026-09-19T14:00:00Z) et les durées (30s, 1h30m) sont des valeurs natives, éliminant tout besoin de conversion de chaîne. Les nombres supportent les séparateurs de lisibilité (1_000_000), les bases binaires (0b1010_1100), octales (0o644) et hexadécimales (0xFF8800), ainsi que les constantes infinity et -infinity. Les booléens (true, false) et le null (null) sont explicitement réservés. Les tableaux acceptent la virgule ou le saut de ligne comme séparateur, tandis que les objets imbriqués utilisent des accolades obligatoires lorsqu'ils apparaissent dans des tableaux, afin d’éviter toute ambiguïté. Exemple tiré du dépôt :

name: 'api-gateway'
port: 8080 # The load balancer expects this port.
timeout: 30s
launch-date: 2027-09-19
allowed-origins: [
    'https://example.com'
    'https://example.org'
]

Le même document en JSON montre la différence de bruit :

{
    "name": "api-gateway",
    "port": 8080,
    "timeout": 30,
    "launch-date": "2027-09-19",
    "allowed-origins": [
        "https://example.com",
        "https://example.org"
    ]
}

Implications pratiques et limites

Le parseur SOML repose sur une grammaire à un seul passage sans regard en avant, ce qui réduit la complexité algorithmique et minimise la consommation de mémoire pendant l’analyse. La règle de typage stricte élimine les comportements divergents : les clés dupliquées, les nombres hors de la plage 64 bits, ou les valeurs ambiguës déclenchent des erreurs plutôt que des interprétations implicites. La forme canonique garantit que deux fichiers équivalents génèrent le même flux d’octets, ce qui est exploitable pour les signatures numériques ou les caches de configuration. Un formatteur dédié, dont les règles sont intégrées à la spécification, préserve les commentaires et l’ordre des membres, contrairement à YAML où les commentaires peuvent être perdus. Cependant, le projet reste à l’état de draft spec et la communauté d’implémentations est encore limitée, ce qui peut freiner l’adoption dans des pipelines CI/CD existants. L’obligation de citer explicitement les types augmente légèrement la verbosité pour des valeurs triviales, mais elle évite les erreurs de conversion fréquentes dans YAML 1.1. Enfin, l’absence de support natif dans les bibliothèques standard de langages majeurs nécessite l’ajout de dépendances tierces, ce qui peut être perçu comme un coût supplémentaire.