Здравствуйте, Sinclair, Вы писали:

S>Иммутабельность означает не просто отсутствие модифицирующих операций, но и наличие операций по построению новых значений на основе существующих.

Думаю, надо расставить все точки на i, а то ты окончательно запутал потенциальных читаталей.

Иммутабельность — это именно то, что означает этот термин.
Это некие гарантии ЯП неизменности неких значений.

наличие операций по построению новых значений на основе существующих

Если речь про структурное построение, а не про арифметические или логические вычисления, то этим св-вом обладают все языки, в которых можно описывать структуры, кортежи или их аналоги.

Наверно ты имел некие св-ва, которая даёт иммутабельность программе?
Например:
1. свойство ссылочной прозрачности, т.к. состояние лямбд неизменно, то любые лямбды становятся чистыми ф-иями;
2. детерминированность по чтению при доступе из разных потоков.

Каждое из этих св-в имеет вполне ощутимые последствия.
(1) даёт возможность не разыменовывать ссылки с целью копирования результата (ссылки на ф-ии в том числе), то бишь можно отложить вычисления "на потом", а будучи однажды вычисленным — заменить ссылку и/или выражение на его значение. При этом, доступ к любым данным по "фиксированному адресу" (например, по коль-угодно глубокому графу) можно заменить ленивой функцией с мемоизацией, которая вычислится лишь однажды.

(2) дает возможность эффективного распараллеливания программ, т.е. без блокировок. Распараллеливания не только по данных, но и вообще по вычислениям, что в связке с мемоизацией, по-сути, выполняет бесконечную бета-редукцию прямо в процессе работы программы, связывая термы с конкретными аргументами.

Что касается неймспейса Immutable и реализаций типов в нём, то, помимо собственно гарантий иммутабельности описанных типов, те реализации позволяют эксплуатировать совсем небольшое подможество св-в иммутабльных типов данных, а именно — детерминированность по чтению из разных потоков. Всё.

Большинство типов из неймспейса Immutable не представляют практического интереса для программиста, такие как ImmutableArray, ImmutableList, ImmutableQueue и т.д., т.к. в реальных сценариях экономят совсем мало на реализации своих аналогов. Иммутабельные хеш-таблицы из этого неймспейса можно вовсе смело сжечь. Более-менее интерес представляют лишь иммутабельный словарь и множество, оба на основе сбалансированного дерева. Единственные, мать его, полезные два типа из всего неймспейса.

Но в этих типах не будет ни ссылочной прозрачности (о которой "знал" бы компилятор или некий пользовательский код, строящий и исполняющий лямбды "на лету"), ни автоматического распараллеливания вычислений с потенциальной мемоизацией (подменой ссылок на термы в процессе аппликации вычисленными значениями) — ничего этого нет. Потому что эти типы неотличимы от мутабельных с т.з. системы типов языка. Да и в самом языке нет пребразований над иммутабельными типами данных и ф-иями/ламбдами поверх них за отсутствием оных.

Плюс рядом же в исходниках появился еще неймспейс Frozen, который описывает иммутабельные типы с точно такими же гарантиями, но обладают меньшей эффективностью при изменении данных.
Зато в неймспесе Frozen уже все представленные типы представляют интерес, т.к. был сделан упор на эффективный лейаут данных в памяти, оптимизированный для чтения на современных архитектурах.

Что же касается "гарантий", который требовал Синклер — он имел ввиду защиту от дурака на уровне ср-в языка.
Например, можно описать обычные типы данных без гарантий иммутабельности, т.е. ни защитив сами данные ни const/readonly, ни дизайном ООП-типов через инкапсуляцию.
Иммутабельность данных может быть обеспечена самим сценарием. Это примерно то же самое, что инкапсуляция на уровне объекта, только уровнем повыше — на уровне некоей подсистемы, если спроектировать её так, чтобы "абстракции не протекали", т.е., чтобы не нарушалась принятая в системе стратегия рассматривать некие данные как иммутабельные, т.е. будучи однажды созданными, сохраняющие затем неизменность до тех пор, пока на эти данные есть ссылки, т.е. пока они нужны.