История изменений
Исправление MOPKOBKA, (текущая версия) :
Про многое уже читал. Вот у Lisp и MUMPS одна проблема, они выбрали одну структуру, и даже не хотят ее превратить в чистую абстракцию. В MUMPS это оправдано сферой применения еще, не очень приятно если в середине процесса часть дерева начнет превращаться в массив, а вот в Lisp, это выглядит странно. Как будто максимум это закостыливание вектора сбоку.
Сейчас прорабатываю эвристики и механизмы для библиотеки работы с cons ячейками. Ничего кроме них не будет внешне. Но внутреннее будет конвертация в зависимости от метода использования в:
- Массив || Отсортировнное множество (atom, i8, i32, i64/f64)
- Хеш-карта
- Разреженный ... ?тензор? (матрица, 3д матрица, 4д матрица, ...) с быстрой операцией transpose (перестановкой row[], col[]), что бы быстрым было и получение значений по ключу, и ключей по значению, как и в PHP операции над значениями будут сохранять вышестоящие значения/ключи, такое сохранение «контекста» полезно, странно что мало где есть
Для облегчения задачи внешне все cons ячейки будут представленны как неизменяемые, для исключения проблемы с отслеживанием изменения середины длинного списка. Ну и базовые методы будут поддерживать ветки для всех структур: map, filter, reduce ...
Исправление MOPKOBKA, :
Про многое уже читал. Вот у Lisp и MUMPS одна проблема, они выбрали одну структуру, и даже не хотят ее превратить в чистую абстракцию. В MUMPS это оправдано сферой применения еще, не очень приятно если в середине процесса часть дерева начнет превращаться в массив, а вот в Lisp, это выглядит странно. Как будто максимум это закостыливание вектора сбоку.
Сейчас прорабатываю эвристики и механизмы для библиотеки работы с cons ячейками. Ничего кроме них не будет внешне. Но внутреннее будет конвертация в зависимости от метода использования в:
- Массив || Отсортировнное множество (atom, i8, i32, i64/f64)
- Хеш-карта
- Разреженный ... ?тензор? (матрица, 3д матрица, 4д матрица, ...) с быстрой операцией transpose (перестановкой row[], col[]), что бы быстрым было и получение значений по ключу, и ключей по значению, как и в PHP операции над значениями будут сохранять вышестоящие значения/ключи, такое сохранение «контекста» полезно, странно что мало где есть
Для облегчения задачи внешне все cons ячейки будут представленны как неизменяемые, для исключения проблемы с отслеживанием изменения середины длинного списка.
Исходная версия MOPKOBKA, :
Про многое уже читал. Вот у Lisp и MUMPS одна проблема, они выбрали одну структуру, и даже не хотят ее превратить в чистую абстракцию. В MUMPS это оправдано сферой применения еще, не очень приятно если в середине процесса часть дерева начнет превращаться в массив, а вот в Lisp, это выглядит странно. Как будто максимум это закостыливание вектора сбоку.
Сейчас прорабатываю эвристики и механизмы для библиотеки работы с cons ячейками. Ничего кроме них не будет внешне. Но внутреннее будет конвертация в зависимости от метода использования в:
- Массив || Отсортировнное множество (atom, i8, i32, i64/f64)
- Хеш-карта
- Разреженный ... ?тензор? (матрица, 3д матрица, 4д матрица, ...) с быстрой операцией transpose, что бы быстрым было и получение значений по ключу, и ключей по значению, как и в PHP операции над значениями будут сохранять вышестоящие значения/ключи, такое сохранение «контекста» полезно, странно что мало где есть
Для облегчения задачи внешне все cons ячейки будут представленны как неизменяемые, для исключения проблемы с отслеживанием изменения середины длинного списка.