設計

dandori は .flow を構文解析し、名前と型を解決します。規則の名前と型は、rulec が ritsu の規則の口を通して渡すものから取り、日付のファイルと帳簿のものは、koyomi と chobo が日付の口と帳簿の口を通して渡すものから取ります。こうしてできた型付きの構文木を、処理の流れに沿って検査します。見るのは、案件の状態、どこでどの変数に値が入るか、すべての分岐、すべての終わり方です。検査を通った構文木は、参照インタプリタがそのまま動かします。シナリオもこの構文木から作ります。五つのジェネレーターは、同じ構文木からプラットフォームごとのコードを生成します。

なぜ別の言語にしたか

rulec が受け持つのは判断です。手順そのもの、手順のあいだの待ち、ほかのシステムへの変更といった、ワークフローを動かすことは、わざと対象から外しています。rulec のステートマシンは状態を呼び出す側に持たせ、rulec が生成する関数は副作用を持ちません。dandori は、その外側を受け持つ言語として、rulec とは別に作りました。

rulec に入れなかった理由は二つあります。一つは、待ちや外部のデータの変更、リトライは、表の行として書けないことです。rulec がステートマシンを宣言の一つとして扱えるのは、遷移を表の行として書けるからで、ワークフローではそれが成り立ちません。もう一つは、rulec が証明できるのは言語が小さいからだということです。ワークフローを入れれば、その小ささが失われます。

その代わり、検査、ジェネレーター、テストをもう一式作ることになりました。一方で、判断の中身の検査（抜けと重なり、単位、丸め）は rulec に任せられるので、dandori の検査はワークフローの形と案件の状態に絞れます。

六つの原則

P1. .flow 自身は判断しない。 .flow の式は値を組み立てられます（レコード、リスト、値を埋め込んだ文字列）が、比較・計算・論理演算は持ちません。分岐は、列挙・bool・オプショナルな値の match だけで、その値は規則かタスクの結果です。タスクに渡すレコードを組み立てたり、通知の文面に注文番号を入れたりしても、何も判断していないので許しています。比べたり計算したりするのは、規則（抜けが無いことを rulec が証明します）か、タスク（API、エージェント、Jev、自分で書くコード）です。
P2. rulec の中には入らない。 dandori が規則を読むのは、ritsu の規則の口からだけです。rulec は、規則について分かっていることを、そこから型のまま渡します。口は dandori を走らせる側が渡し（ritsu dandori は rulec を渡します）、rulec は dandori を知りません。koyomi の日付のファイルと chobo の帳簿も同じく、日付の口と帳簿の口から読みます。
P3. 意味を決めるのは参照インタプリタ一つ。 各プラットフォームで動くものは、どれもこれと突き合わせます。
P4. ループには回数の上限を書き、再帰は無い。 そのため、一回の実行履歴の長さには上限があり、動かす前に数えられます。
P5. 前もって分からないことは、受け取るときに確かめる。 呼び出しの結果は、届いたときに型を確かめ、合わない値ならその場で実行を失敗させます。
P6. プラットフォームによって意味が変わる機能は、同じ意味を保てるプラットフォーム向けにだけビルドする。 ほかでは E050 でエラーにします。キャンセルの後始末（on cancel）、名前で送られてくるイベント（event）、実行がいまどこにいるかを聞くサービスのメソッド（status）は、いまは Temporal 向けにしかビルドできません。意味は変えず、呼び出す場所や費用だけを変える項目（queue、image、規則の local）は、効かないプラットフォームでは無視します。

P6 は、Temporal を主なプラットフォームにしたときに加えた原則です。それまでは、どのプラットフォームでも動くものだけを言語に入れていました。しかし、Temporal でしか意味を持たない機能を締め出すと、Temporal で書けるワークフローが狭くなります。かといって、ほかのプラットフォームで黙って別の意味にすれば P3 が崩れます。そこで、ビルドできるプラットフォームでは参照インタプリタと同じ意味でビルドし、できないところではエラーにすることにしました。こうすれば、参照インタプリタが決める意味は一つのままです。

詳しい記録

DESIGN.md に、ここに挙げたものを含むすべての決定について、理由、採らなかった案、残っている課題、確かめるために動かしたことを書いています。