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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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