YAMLの「no」がfalseになる問題を、Sindre Sorhusが新しい設定フォーマットSOMLで解決

SOML – A Config Format for Humans

JSONの厳格さとYAMLの書きやすさを両立させる設定フォーマットSOMLを、Sindre Sorhusが公開した。値の型を内容ではなく構文で決めるのが最大の特徴で、'123'は文字列、123は整数、country: noはエラーになる。日付・時刻・期間も値として扱い、コメントやブロック文字列、正規化形式、約1000ケースの適合テストを備える。まだドラフト仕様だ。

SOMLはYAMLの良いところを残し、痛いところを取り除く。YAMLでは値の内容が型を決めてしまうが、SOMLでは構文が決めるので、どの実装でも'no'は文字列、3.10は浮動小数点数、2は整数になる。
  1. layer8

    「見たままが得られるもの: […] '10.20' と 10.20 は、書かれたとおりに文字列と浮動小数点数である。」

    これは仕様が不十分な上に、そもそも正しくないように思える。単精度のバイナリ IEEE 754 浮動小数点数だと仮定すると、10.20 は実際には 10.19999980926513671875 になる。倍精度なら 10.199999999999999289457264239899814128875732421875 だ。つまり見たままが得られるものではなく、そもそも正確に何が得られるのかも不明確だ。

    「値の型はその構文から決まり、内容から決まることは決してない […] allowed-origins: [

    'https://example.com'

    'https://example.org'

    ]

    これは URL に見えるが文字列である。もしこうだったらどうなる?

    「allowed-origins: [

    'httpș://example.com'

    'ħttps://example.org'

    ]

    これもやはり文字列なので SOML パーサにとっては問題ないが、値のアプリケーションレベルの型という観点ではおそらく有効な設定ではない。アプリケーションのスキーマが設定言語よりも型について具体的な考えを持つようになった途端、構文が型を教えてくれるというのは限られた有用性しか持たない。

  2. lightandlight

    皮肉なことに、このプロジェクトは LLM が生成したように見える。

    あなたのプロジェクトがなぜ重要かを Claude がどう解釈しているかを読みたくはない。あなた自身が直接語ってほしい。

  3. ActionHank

    正直に言うと、こういう「より人間らしく」するソリューションが出てくるたびに、彼らはただ構造や構文を取り除いているだけだ。

    おそらく、それらを学ぶ必要をなくすためで、そうすれば道端の誰でもファイルを編集できるようになるが、そうしたガードレールなしでは、たいてい何か分かりにくい形でひどく壊れる。

    そして結局は、より多くの暗黙のルールを伴う新たな「人間的な」何かを発明することに戻り、このサイクルが続く。

  4. mofle

    皆さん、こんにちは。これに取り組んでいるのは私(人間)です。まだ初期段階です。何年も前から欲しかったものですが、今までそれに投資する時間がありませんでした。

    すでに私のウェブサイトの frontmatter を動かしています: https://github.com/sindresorhus/sindresorhus.github.com/blob...

  5. james_marks

    タイトルから、これは人間を設定するための仕様なのかと思った。それが何を意味するのかよく分からないし、今も分からないままでがっかりしている。

この日のほかの記事

2026-11-02