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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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