Які практичні наслідки теорії типу гомотопії в програмуванні?

Я тільки починаю вивчати Haskell, після приходу зі світу JavaScript / Ruby. Я натрапив на https://github.com/HoTT та книгу теорії типу гомотопії , яку я дуже прагну прочитати.

Однак я буду вивчати поняття теорії математики та типів, коли я піду, тому, схоже, пройде багато часу, перш ніж я зрозумію, що означатиме теорія типу гомотопії для практикуючого програміста.

Чи могли б ви описати, який вплив теорія типу гомотопії матиме на програмуванні на практиці для мирян? Наприклад, чи спростить писати певні речі легше? Якщо так, то які речі? Або це дозволить вам робити нові речі в програмуванні, які раніше не було можливо? Якщо так, то які речі?

Дякую, дуже з нетерпінням чекаю, що я оберну голову навколо цього на більш базовому рівні.

Одне з потужних речей, які компілятори можуть зробити під час фази оптимізації, - це замінити неефективні подання на еквівалентні. Наприклад, у Haskell ви можете використовувати лінивий список для обчислення суми чисел, але компілятор GHC Haskell визнає, що це еквівалентно використанню ітерації з тимчасовою змінною. Таким чином, ви можете програмувати проти простої абстракції, на яку легко міркувати, тоді як ваш виконуваний файл використовує уявлення, що краще підходить до апаратної платформи (а це набагато важче міркувати про масштаб).

Однак еквіваленти, відомі компілятору, здебільшого обмежені добре відомими та дослідженими структурами даних, такими як синтез потоків для списків. Ви можете визначити власні еквіваленти у вихідному коді (використовуючи пару функцій перетворення, які складаються з ідентичності в будь-якому напрямку), але вам доведеться застосувати їх вручну, і це може стати складним, щоб вибрати правильний тип, який потрібно використовувати в усіх місцях щоб уникнути зайвих конверсій.

Тепер давайте уявимо собі світ, де ви маєте визначити "вищі індуктивні типи", скажімо, канонічна карта пошуку. Цей тип має декілька конструкторів для різних типів карт: двійковий пошук, AVL, червоно-чорний, Trie, Patricia тощо. Поряд із типовими конструкторами даних ви також визначаєте тип еквівалентності, що фіксує, можливо, кілька перетворень між цими поданнями, де різні конверсії пропонують різні розміри ефективності (тобто час проти пам'яті).

Що робити, якщо компілятору вдалося використати це поняття для прозорого переписування представлень на карті, так само, як це можна зробити сьогодні зі злиттям списку? Тим часом у вашому коді ви працюєте з конструкцією, про яку просто провести міркування (і полегшує перевірку роботи, якщо ви перебуваєте в такому середовищі). Це може здатися як абстрактний інтерфейс з декількома реалізаціями, але він включає свободу вибору будь-якої реалізації та компілятор прозоро підміняє інший за необхідності, не впливаючи на значення програми.

HoTT дає нам теоретичну основу для виправдання цього фантазійного механізму переписування та цих чітко визначених типів, оскільки він сприяє поняттю еквівалентності як рівносильному рівності. Залишається побачити, як це насправді вийде на практиці, але це дає нам теоретичну основу, на якій базуватись майбутні роботи.