Unison

https://gyazo.com/335ee24bd90ea225c573ab967d9b842c

参考

Each Unison definition is identified by a hash of its syntax tree.

Put another way, Unison code is content-addressed.

例えば、以下のようなコードは

code:unison(hs)

increment : Nat -> Nat

increment n = n + 1

実体は以下のようなコードとして格納される

code:unison(hs)

同じ名前で別のハッシュを参照することはできる

ハッシュが指す構造が変わることはない

正確な実装を一意に特定し、全ての依存関係を突き止める

ucm

ASTがhash化されて保存されるレジストリ

コードを書くと型チェックされて、通ると追加できる

$ nix-shell -p unison-ucm

$ ucm

起動

algebraic effectsのことをAbilityと読んでるらしい

遅延評価

メリット

分散プログラミングの簡略化

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すれば誰もがそれを再利用できる

純粋な計算のテストも、一度通ることを確認できれば、それ以降は実行する必要がない

依存関係の衝突が無い

flatに依存関係を解決することで、dependency hellみたいにならない

複数のライブラリ間で同じ名前のものがあっても、ハッシュは別のものを指しているので問題にならない

Typed, durable storage

プログラムと、(DBなどの)Storageの間でやり取りする際に、データのシリアライズをすることはあるあるだが、面倒

Unisonでは自動であらゆる値（関数や関数を含む値を含む）を永続化したり、後で永続化解除することができる

ここで永続化されたデータは、未来永劫Unisonプログラムと互換性があるものになる

encode/decode部分のライブラリのバージョンが上がって互換性がなくなる、なんてことが起きない

コードを扱うための優れたツールの実現

Unisonのコードベースは、保存するすべてのものの型を把握し、完璧なコンパイルキャッシュ、依存関係の完璧な知識、型ベースの検索のためのインデックスなどを持つ、と言った感じのDBになっている

コードに使っているあらゆる関数などを閲覧でき、そこにリンクされたdocsを表示できる

リファクタリングの構造化

Unisonでは、どの名前がどのハッシュにマッピングされるかを変更する場合、テキストファイルをその場で変更し、誤解を招くコンパイルエラーや失敗したテストの長いリストを修正するという典型的なアプローチではなく、構造的なリファクタリングセッションで行われます。Unisonのコードベースは、リファクタリングの途中であっても、決して壊れた状態にはなりません。

などなど