show "символов"

show - демонстрирует имя, значение и список свойств символа … “найденного путем применения get к любому и следующим аргументам”. О процитированном в кавычках можно пока только догадываться, хотя функция get уже акцентировалась. Поэтому процитируем для неё её “документацию“ : “Извлекает значение из свойств символа или из списка. Из первого аргумента … значения извлекаются последовательными шагами либо путем извлечения значения (если следующий аргумент равен нулю), либо свойства из символа, CDR связанного элемента (если следующий аргумент является символом), n-го элемента (если следующий аргумент является положительным числом) или n-го CDR (если следующий аргумент является отрицательным числом) из списка.” Про списки отдельная тема, а это повод вернуться к теме символа, его структуре.
Напомним, что символы типизируются как специфический сивол NIL, внутренние, внешние (символы базы данных) и транзитные и акцентируем ещё раз, что символы, по сути - список параметров, фрейм, объект, который, кстати, может быть и функцией … таблица, слово Форта, фрагмент ассоциативного массива … “список пар“ … и пара, опять же в вычислительной архитектуре - базовая сущность или фундамент любой вычислительной структуры. Особняком от этого стоят числа - как автореферентные символы, содержащие в своих именах значения и не требующие дополнительных определений. Хотя мы типизируем числа как целые, “длинные“ целые, с плавающей точкой, бинарные, шестнадцатиричные … и так далее … то есть и числа могут символизироваться и иметь определенные свойства. А поскольку все сущности ещё и, естественным образом, группируются, классифицируются по определенным параметрам, категоризуются (для чего и неизбежны скобки в линейной записи), то символ - ключевой тип, а пара - ключевая структура в вычислительной архитектуре … и моделировании, в принципе. То есть символ как модель … он же объект, он же фрейм, он же функция … и так далее …
То есть, мы могли бы назвать символ моделью, что, кстати, в PicoLisp даже напрашивается, поскольку символы имеют отношения (есть специальный класс для этого) и в базе данных реализована гибридная схема “сущность-отношение“ и “не реляционные объекты“. То есть, опять упираемся в те же пары, как структуры и их списки, имеющие “объектную иерахию” или таблицы и метатаблицы в интерпретации системы Lua. Самая общая модель в вычислитеьных (информационных) процессах всегда будет модель акторов или интерпретаторов, обменивающихся месседжами. Эти месседжи и есть наши s-выражения, интерпретирующиеся интерпреаторами, которые мы тоже символизруем или именуем, кодируя. То есть в структуре ленты пара-слотов у нас всегда блоки выражений. А “куча“ не что иное как “бинарное дерево“ и все равно базируется на “ассоциативном массиве“ объектов, у которых могут быть в свойствах “мета“ или специфичные ссылки, определеющие любую структуру - иерархию или сеть. В основе любого мультиграфа, гиперграфа и псевдографа универсальный двудольный граф. Проблема в динамике, которая накладывается на регулярные конечные решетки, в перманентности против персистентности.
Subscribe to my newsletter
Read articles from Sergey Shishkin directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by

Sergey Shishkin
Sergey Shishkin
Всегда чему-то учусь!