Unison
参考
>#WIP
Each Unison definition is identified by a hash of its syntax tree.
Put another way, Unison code is content-addressed.
例えば、以下のようなコードは
unison(hs)increment : Nat -> Nat
increment n = n + 1実体は以下のようなコードとして格納される
unison(hs)increment = (#arg1 -> #a8s6df921a8 #arg1 1)「
increment 」などの名前は人間が読むために使うメタデータに過ぎない同じ名前で別のハッシュを参照することはできる
ハッシュが指す構造が変わることはない
正確な実装を一意に特定し、全ての依存関係を突き止める
ucm
ASTがhash化されて保存されるレジストリ
コードを書くと型チェックされて、通ると追加できる
$ nix-shell -p unison-ucm$ ucm起動
algebraic effectsのことをAbilityと読んでるらしい
遅延評価
Exercismにある
メリット
説明が長々書かれているが具体例見ないと全くわからんな
分散プログラミングの簡略化
RPCのように、離れた場所でプログラムを共有するのが自然に行える
> the sender ships the bytecode tree to the recipient, who inspects the bytecode for any hashes it's missing. If it already has all the hashes, it can run the computation; otherwise, it requests the ones it's missing and the sender syncs them on the fly. They'll be cached for nexttime.
build時間の削減
hash化された定義は以降は変更されることがないので、一度buildすれば誰もがそれを再利用できる
Cachixと同じ考え方
純粋な計算のテストも、一度通ることを確認できれば、それ以降は実行する必要がない
依存関係の衝突が無い
flatに依存関係を解決することで、dependency hellみたいにならない
複数のライブラリ間で同じ名前のものがあっても、ハッシュは別のものを指しているので問題にならない
Typed, durable storage
プログラムと、(DBなどの)Storageの間でやり取りする際に、データのシリアライズをすることはあるあるだが、面倒
Unisonでは自動であらゆる値（関数や関数を含む値を含む）を永続化したり、後で永続化解除することができる
ここで永続化されたデータは、未来永劫Unisonプログラムと互換性があるものになる
encode/decode部分のライブラリのバージョンが上がって互換性がなくなる、なんてことが起きない
コードを扱うための優れたツールの実現
Unisonのコードベースは、保存するすべてのものの型を把握し、完璧なコンパイルキャッシュ、依存関係の完璧な知識、型ベースの検索のためのインデックスなどを持つ、と言った感じのDBになっている
コードに使っているあらゆる関数などを閲覧でき、そこにリンクされたdocsを表示できる
リファクタリングの構造化
Unisonでは、どの名前がどのハッシュにマッピングされるかを変更する場合、テキストファイルをその場で変更し、誤解を招くコンパイルエラーや失敗したテストの長いリストを修正するという典型的なアプローチではなく、構造的なリファクタリングセッションで行われます。Unisonのコードベースは、リファクタリングの途中であっても、決して壊れた状態にはなりません。
などなど
なんかめちゃくちゃヤバそうな言語だな