Проблема организации памяти "динамическими списками над регулярным массивом" связана, в конце концов, с проблемой фрагментации памяти. Зачем нам сборщики мусора? Можно ли кодить без мусора? Гипотеза в том, что можно. В конце концов, все программирование можно описать метафорой фрагментации памяти в блоки или контейнеры и системой их управления. Если бы не было динамики, можно было бы обойтись таблицами или матрицами, где мы просто бы переписывали содержимое их элементов с адресным доступом. Но что делать, когда линамика рушит всю эту регулярность, а память не только не матричная, но просто линейная, а, нам например, надо элементарно вставить новый элемент во "внутрь" или даже изменить содержимое, не совпадающее с прежним размером.
Один из методов - иметь два массива, один из которых типа мета-массива с адресами или размерами блоков, который демонстрирует "структуру" основного массива, связнах блоков. Но тогда, чтобы решить проблему плотности памяти необходимо при вставки или удалении любого элемента "внутри", перезаписывать оба массива или их части. Что чаще всего надо делать не часто, но при напряженной динамики может превратиться в существенные накладные расходы.
Другой метод, акцентируемый проектом PicoLisp и, в приницпе, идеей связных списков, просто все время добавлять новые элементы в конец списка. Но тогда лучше не изменять размеры уже существующих элементов, а если у нас, например, новый параметр у объекта, с которым надо постоянно работать, то это вынуждает "юзать каретку" иногда неоправдано слишком далеко. Отсюда идея выделять "постоянные параметры", которые можно "перезаписывать" при необходимости некоторой процедурой балансировки. Отсда, собственно идея акцентировать "постоянные" параметры, позиционирование которых можно при случаи оптимизировать а так же тразитивные, параметры, которые приходят из внешей среды (создают внешние эффекты).
Что лучше? Пока не понятно. Вероятно, что балансировку можно сочетать с первым подходом. Точно ясно только то, что на базовым уровне у нас есть блоки, параметрами которых являются адрес и размер ... и это может меняться вместе с содержимым. Блоки именуются или являются анонимными "лямбдами". Собственно, исчисление последних, действительно, является базовым и должно быть реализовано в хостовых системах, в первую очередь и, даже с поддержкой графического интерфейса! Это и есть система без синтаксиса! И она может быть описана гораздо проще, чем существующие тома с мультиплицированными друг друга теориями! По факту! Демонстративно!
P.S. И ещё в связи с памятью два важных её принициа - персистентность и эластичность, которые связаны между собой и дополняют друг друга. И решения для обоих - распределенная база данных. Не обязательно иметь "постоянно расширяющуюся" память. Наши блоки или контейнеры, в конце концов, всегда конечны, а вот распределение и рещает прблему этого перманентного расширения. Какие здесь базовые значения параметров зависит от аппартных или технологических возможностей, скорости доступа ... На текущий момент это 4 - 10 Гб ... Но, кстати, и это может быть просто динамическим параметром. Ну и, если в двух словах о революционности Lisp-идеи, то она вся в точечной паре, в CONS, а в скобочном синтаксисе, как некоторые пытаются интерпретировать. По сути в фундаментальности представления ассоциативного массива или двудольного графа, которые являются базой для любых таблиц, бинарных деревьев и, в приниципе, любых сетей.
Постоянно перечитывать! От автора идеи потоков!
