show "символов"

show - демонстрирует имя, значение и список свойств символа … “найденного путем применения get к любому и следующим аргументам”. О процитированном в кавычках можно пока только догадываться, хотя функция get уже акцентировалась. Поэтому процитируем для неё её “документацию“ : “Извлекает значение из свойств символа или из списка. Из первого аргумента … значения извлекаются последовательными шагами либо путем извлечения значения (если следующий аргумент равен нулю), либо свойства из символа, CDR связанного элемента (если следующий аргумент является символом), n-го элемента (если следующий аргумент является положительным числом) или n-го CDR (если следующий аргумент является отрицательным числом) из списка.” Про списки отдельная тема, а это повод вернуться к теме символа, его структуре.

Напомним, что символы типизируются как специфический сивол NIL, внутренние, внешние (символы базы данных) и транзитные и акцентируем ещё раз, что символы, по сути - список параметров, фрейм, объект, который, кстати, может быть и функцией … таблица, слово Форта, фрагмент ассоциативного массива … “список пар“ … и пара, опять же в вычислительной архитектуре - базовая сущность или фундамент любой вычислительной структуры. Особняком от этого стоят числа - как автореферентные символы, содержащие в своих именах значения и не требующие дополнительных определений. Хотя мы типизируем числа как целые, “длинные“ целые, с плавающей точкой, бинарные, шестнадцатиричные … и так далее … то есть и числа могут символизироваться и иметь определенные свойства. А поскольку все сущности ещё и, естественным образом, группируются, классифицируются по определенным параметрам, категоризуются (для чего и неизбежны скобки в линейной записи), то символ - ключевой тип, а пара - ключевая структура в вычислительной архитектуре … и моделировании, в принципе. То есть символ как модель … он же объект, он же фрейм, он же функция … и так далее …

То есть, мы могли бы назвать символ моделью, что, кстати, в PicoLisp даже напрашивается, поскольку символы имеют отношения (есть специальный класс для этого) и в базе данных реализована гибридная схема “сущность-отношение“ и “не реляционные объекты“. То есть, опять упираемся в те же пары, как структуры и их списки, имеющие “объектную иерахию” или таблицы и метатаблицы в интерпретации системы Lua. Самая общая модель в вычислитеьных (информационных) процессах всегда будет модель акторов или интерпретаторов, обменивающихся месседжами. Эти месседжи и есть наши s-выражения, интерпретирующиеся интерпреаторами, которые мы тоже символизруем или именуем, кодируя. То есть в структуре ленты пара-слотов у нас всегда блоки выражений. А “куча“ не что иное как “бинарное дерево“ и все равно базируется на “ассоциативном массиве“ объектов, у которых могут быть в свойствах “мета“ или специфичные ссылки, определеющие любую структуру - иерархию или сеть. В основе любого мультиграфа, гиперграфа и псевдографа универсальный двудольный граф. Проблема в динамике, которая накладывается на регулярные конечные решетки, в перманентности против персистентности.