LINUX.ORG.RU

История изменений

Исправление 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 ячейки будут представленны как неизменяемые, для исключения проблемы с отслеживанием изменения середины длинного списка.