プログラミングにおけるホモトピー型理論の実際的な意味は何ですか？

JavaScript / Rubyの世界から来て、Haskellを学び始めたばかりです。私が遭遇しているhttps://github.com/HoTTとホモトピー型理論の本、私は非常に読み熱心です。

しかし、数学と型理論の概念を学んでいるので、実践的なプログラマにとってホモトピー型理論が何を意味するかを理解するまでに時間がかかるようです。

素人にとって、ホモトピー型理論が実際にプログラミングに与える影響について説明していただけますか？たとえば、特定のことをより簡単に記述できるようにしますか？もしそうなら、どのようなものですか？それとも、以前は不可能だったプログラミングの新しいことを行うことができますか？もしそうなら、どのようなものですか？

おかげで、もっと基本的なレベルで頭を包むのを楽しみにしています。

コンパイラが最適化フェーズで実行できる強力な機能の1つは、非効率な表現を同等の表現に交換することです。たとえば、Haskellでは、レイジーリストを使用して数値の合計を計算できますが、GHC Haskellコンパイラーは、これが一時変数での反復の使用と同等であることを認識します。そうすれば、推論するのが簡単な単純な抽象化に対してプログラムを作成できますが、実行可能ファイルはハードウェアプラットフォームにより適した表現を利用します（大規模な推論がはるかに困難です）。

ただし、コンパイラに既知の同等性は、リストのストリームフュージョンなど、よく知られ研究されているデータ構造にほとんど制限されています。ソースコードで独自の同等性を定義することもできます（どちらの方向でもIDに変換する変換関数のペアを使用）が、それらを手動で適用する必要があり、すべての場所で使用する適切なタイプを選択するのが難しい場合があります過度の変換を避けるため。

ここで、「より高い帰納的タイプ」を定義できる世界、例えば標準的なルックアップマップを想像してみましょう。このタイプには、バイナリ検索、AVL、赤黒、トライ、パトリシアなど、さまざまな種類のマップ用のコンストラクターがいくつかあります。典型的なデータコンストラクターとともに、これらの表現間の複数の変換をキャプチャする等価タイプも定義します。変換により、さまざまな次元の効率（つまり、時間とメモリ）が提供されます。

コンパイラーがこの概念を使用して、マップ表現を透過的に書き換えることができたとしたら、それは今日のリスト融合と同じ方法でしょうか？一方、コードでは、最も簡単に推論できる構造で作業することができます（そのような環境にいる場合は、証明作業が簡単になります）。これは、複数の実装を持つ抽象インターフェースのように聞こえるかもしれませんが、任意の実装を選択し、プログラムの意味に影響を与えることなくコンパイラーが必要に応じて透過的に別のものを置き換える自由が含まれています。

HoTTは、この派手な書き換えメカニズムとこれらの豊富に定義された型を正当化するための型理論的基盤を提供します。これが実際にどのように実際に機能するかはまだわかりませんが、将来の作業の基礎となる理論的な枠組みを提供します。