str - это string, а не struct или strip

Чтобы не выделять специальные посты для struct (работает со структурами нативного Си) или strip (удаляет кавычки) включил их здесь, чтобы в очередной раз акцентировать ущербность идеи сокращения лексем. Опять же, если используется, в крайних случаях аббревиатура, то это должно быть последовательно, а когда у нас есть тот же класс +String (для отношений строковых транзитных символов) с “полным обозначением”, то это точно путает. Хотя в документации указано, что этот класс в настоящее время не используется. Тем более.

Концепция строки для систем символьных трансформаций одна из самых важных и может быть даже важнее концепции числа, но ей уделяется крайне мало внимания. В то время как неявно, идея проявляется повсюду, скрыта в тех же терминах “символ“ и “месседж“ или “сериализации“ … и т.д. и т.п. То есть, это то, с чего надо бы начинать в принципе и из-за чего весь “сыр-бор” … проблемы мутабельности, динамичности, побочных эффектов и … прочего, в частности, связанного с фрагментацией и “сборкой месора“. Если бы мы работали только с числами и регулярными массивами, то не надо было бы “городить огродов” и ломать копья вокруг моделирования символьных аппликаций.

Итак, str - в первой форме строка разбирается в список, вторая форма выполняет обратную операцию, создавая строку из списка, а str? - возвращает аргумент, если это транзитный символ (строка!), в противном случае NIL.

А еще аббревиатура используется как префикс strDat (преобразует строку в формате даты текущей локали в дату), суффикс datStr (форматирует дату в соответствии с текущей локалью), telStr (форматирует номер телефона в соответствии с текущей локалью) и даже как корень с другими префиксами и суффиксами genStrKey (генерирует уникальную строку для дерева базы данных, добавляя столько последовательностей "# ", сколько необходимо). То есть в контексте для дат, ключей и “телефона“ на эти “символы“ будут еще указания и комментарии.

https://picolisp.tiddlyhost.com/#str