list vs массива

Ещё одна классическая функция Lisp, простая для понимания, но инициализируящая принципиальные аспекты организации памяти в вычислительной архитектуре. 5-ого января акцентируем целых пять функций их банальным перечислением - maplist , lst? , lst/3 , list , listen .

А теперь приведем ссылку на статью автора PicoLisp “Воздержание от массивов“.

Цитата из статьи: “Действительно ли нужны массивы ? … короткий ответ будет: "Нет". Преимущества в эффективности не перевешивают недостатки повышенной сложности.” С таким категоричным утверждением вряд ли согласятся, например аппологеты APL, Но, чтобы занять определенную позицию нужны исследования и эксперименты, но кто ими будет заниматься? Практики ломают копья вокруг шитого кода аппликативного Форта и его двухстековой архитектуры, где мы видим, что любой код верхнего уровня всегда будет уступать нативному или ассемблеру. Но так устроена современная аппаратная архитура, в основе которой лента памяти машин Тьюринга или Поста. А представим, что у нас две ленты? То есть машина, принципиально, двухстековая или стек точечных пар. И тогда мы получаем некоторые новые возможности.

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

Когда-то я пытался, работая с разреженными матрицами, конструировать динамические структуры и понял, что все равно для их реализации требуется минимум два массива. То есть вся проблема в этой самой динамичности структур. Да, любая динамичная структура накладываетс на регулярную, но это требует увеличения размеров последней, чтобы не потерять информацию о том, что и куда было положено. И из-за этого возникают проблемы фрагментации и дефрагментации, неизбежная сериализация. Так что, остается поверить автору PicoLisp, который, например, мне уже помог снять с повестки целых два напраления - Форт и АПЛ … и скорее всего, тот же Смолтолк, но об этом надо говорить в связи с объектами. Опять же, в любом случае, для систем персональных баз знаний и, в принципе, систем, моделирующих автоматизацию интеллектуальных операций, PicoLisp кажется идеальной платформой.