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

V>>Вдогонку, у дотнета уже были интерфейсы, описывающие АПИ иммутабельных коллекций, навроде IReadOnlySet и т.д.
S>Вы по-прежнему не понимаете смысл иммутабельности.

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


S>IReadOnlySet, IReadOnlyList и прочие никакого отношения к иммутабельности не имеют.

Имеют такое же отношение, как и IImutableList и Ко.
Это высказывание — вполне себе тезис.


V>>Выбранное название неймспейса сбивает с толку, бо там речь не об иммутабельности как таковой, а об эффективных способах порожения read-only коллекций. ))
S>Нет. Речь там именно об иммутабельности, а не о read-only.

Я на это уже отвечал — там речь лишь о некоторых алгоритмах над некоторыми иммутабельныим структурами данных.
Есть несколько конекретных типов, помеченные как sealed, которые согласно дизайну являются иммутабельными.
А система реализованных интерфейсов — нет, это просто "вербальные соглашения".

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


V>>Например, неэффективной будет реализация на основе некоего FrozenSet, т.к. потребует копирования коллекций целиком при порождении новых коллекций, т.е. "изменения" их в ФП-стиле.
S>А то.

Что, однако, верно только для сценариев, где данные активно изменятся.
FrozenXXX были созданы для других сценариев — где данные читаются намного чаще, чем изменяются.

Для сравнения, есть структура-обертка ImmutableArray, в нём данные при изменении каждый раз копируются.
Собсно, до введения такого типа в стандартные либы, аналогичная обёртка была, наверно, в каждой конторе, которые разрабатывают под дотнет.
По смыслу поведение этого типа больше просится во Frozen-неймспес, бо та же стратегия... но уже реализовали ранее в Immutable, бгг...
У нас в core-библиотеке эта обертка называется ReadOnlyArray. В Unity тоже и вообще ты можешь найти многие сотни аналогичных реализаций в открытых проектах на дотнете.

Еще пара замечаний относительно FrozenXXX:

нет никаких требований копирования при реализации, ты можешь рядом делать свои реализации со своей стратегией;

методы-расширения, типа ToFrozenSet(), берут на входе неиммутабельные последовательности (или множества) и создают копии данных, т.е. в точности как в вслучае ToImmutableSet();

ImmutableSet<T> — это абстрактный класс, есть несколько его реализаций, все они иммутабельны by design;

идея Frozen-коллекций — это расположить данные в памяти таким образом, чтобы они на современной аппаратуре были эффективны для чтения.
Например, реализация SmallFrozenSet хранит данные в линейном массиве и ищет их линейным поиском, а хеш-реализации имеют более эффективное представление корзин в памяти на тру-иммутабельных структурах Bucket { int StartIndex; int EndIndex; };

мы именно с тобой обсуждали N-арные деревья, т.е. ты должен хорошо понимать, что нет никакого запрета строить иммутабельные деревья из таких структур данных, сбалансированных с точностью от 1 до некоего выбранного max N узлов; т.е., при создании нового корня дерева в общем случае будут создаваться копии меньшего кол-ва узлов, чем для двоичных узлов, но в каждом узле будет больше элементов. До какого-то N это выгодная стратегия на современном оборудовании.

В любом случае, рассуждать об иммутабельности или нет немспейса Frozen было заведомо глупо — типы данных там точно так же иммутабельны by design, как и в неймспейсе Immutable.
Это просто "еще одна реализации иммутабельности" для еще одного популярного сценария.

Сравнить с тем же AST, где количество операций чтения примерно равно кол-ву операций записи.
Разумеется, для сценария построения и обработки AST выгодней брать иммутабельные графы, как оно есть в AST-графе того же Рослина — там AST описано на основе иммутабельных типов.
Жаль, на момент разработки Рослина еще не было типов ImmutableList или ImmutableStack, поверх которых легко строить иммутабельные лиспоподобные графы.

Однако, если по однажды построенной иммутабельной AST многократно работает некий "вычислитель" (допустим, стековая машинка), то выгодней представить это AST в линейном виде в памяти, собсно, как оно и есть в реализации Frozen-коллекций.

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

V>>Вдогонку, у дотнета уже были интерфейсы, описывающие АПИ иммутабельных коллекций, навроде IReadOnlySet и т.д.
S>Вы по-прежнему не понимаете смысл иммутабельности.

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


S>IReadOnlySet, IReadOnlyList и прочие никакого отношения к иммутабельности не имеют.

Имеют такое же отношение, как и IImutableList и Ко.
Это высказывание — вполне себе тезис.


V>>Выбранное название неймспейса сбивает с толку, бо там речь не об иммутабельности как таковой, а об эффективных способах порожения read-only коллекций. ))
S>Нет. Речь там именно об иммутабельности, а не о read-only.

Я на это уже отвечал — там речь лишь о некоторых алгоритмах над некоторыми иммутабельныим структурами данных.
Есть несколько конекретных типов, помеченные как sealed, которые согласно дизайну являются иммутабельными.
А система реализованных интерфейсов — нет, это просто "вербальные соглашения".

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


V>>Например, неэффективной будет реализация на основе некоего FrozenSet, т.к. потребует копирования коллекций целиком при порождении новых коллекций, т.е. "изменения" их в ФП-стиле.
S>А то.

Что, однако, верно только для сценариев, где данные активно изменятся.
FrozenXXX были созданы для других сценариев — где данные читаются намного чаще, чем изменяются.

Для сравнения, есть структура-обертка ImmutableArray, в нём данные при изменении каждый раз копируются.
Собсно, до введения такого типа в стандартные либы, аналогичная обёртка была, наверно, в каждой конторе, которые разрабатывают под дотнет.
По смыслу поведение этого типа больше просится во Frozen-неймспес, бо та же стратегия... но уже реализовали ранее в Immutable, бгг...
У нас в core-библиотеке эта обертка называется ReadOnlyArray. В Unity тоже и вообще ты можешь найти многие сотни аналогичных реализаций в открытых проектах на дотнете.

Еще пара замечаний относительно FrozenXXX:

нет никаких требований копирования при реализации, ты можешь рядом делать свои реализации со своей стратегией;

методы-расширения, типа ToFrozenSet(), берут на входе неиммутабельные последовательности (или множества) и создают копии данных, т.е. в точности как в вслучае ToImmutableSet();

ImmutableSet<T> — это абстрактный класс, есть несколько его реализаций, все они иммутабельны by design;

идея Frozen-коллекций — это расположить данные в памяти таким образом, чтобы они на современной аппаратуре были эффективны для чтения.
Например, реализация SmallFrozenSet хранит данные в линейном массиве и ищет их линейным поиском, а хеш-реализации имеют более эффективное представление корзин в памяти на тру-иммутабельных структурах Bucket { int StartIndex; int EndIndex; };

мы именно с тобой обсуждали N-арные деревья, т.е. ты должен хорошо понимать, что нет никакого запрета строить иммутабельные деревья из таких структур данных, сбалансированных с точностью от 1 до некоего выбранного max N узлов; т.е., при создании нового корня дерева в общем случае будут создаваться копии меньшего кол-ва узлов, чем для двоичных узлов, но в каждом узле будет больше элементов. До какого-то N это выгодная стратегия на современном оборудовании, потому что деревянная в памяти структура в общем случае обладает худшей локальностью, т.е. синтетические тесты, где в памяти только содаются узлы тестируемого дерева, могут сильно врать насчёт его эффективности.

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

В любом случае, рассуждать об иммутабельности или нет немспейса Frozen было заведомо глупо — типы данных там точно так же иммутабельны by design, как и в неймспейсе Immutable.
Это просто "еще одна реализации иммутабельности" для еще одного популярного сценария.

Сравнить с тем же AST, где количество операций чтения обычно примерно равно кол-ву операций записи.
Разумеется, для сценария построения и обработки AST выгодней брать иммутабельные графы, как оно есть в AST-графе того же Рослина — там AST описано на основе иммутабельных типов.
Жаль, на момент разработки Рослина еще не было типов ImmutableList или ImmutableStack, поверх которых легко строить иммутабельные лиспоподобные графы, бгг.

Однако, если по однажды построенной иммутабельной AST многократно работает некий "вычислитель" (допустим, стековая машинка), то выгодней представить это AST в линейном виде в памяти, собсно, как оно и есть в реализации Frozen-коллекций.