print как тема

Авторская документация состоит из двух основных частей - туториала или мануала и референций. Вот с учебника или руководства можно начать исследование функциональности системы с точки зрения авторских приоритетов. И первой функцией после самого интепретатора является prin или целый набор функций, собственно, обзора самой системы … “некоторые функции для просмотра фрагментов данных и кода в работающей системе“ … Ну, а включая и параметр лексических аналогий акцентируем print, pp, pr, prBase64, prEval, pretty, prinl, println, printsp …

В списке ещё “затесалась” pre? для проверки, является ли “что-то“ префиксом “чего-то“, но это акцентирование обусловлено присутствием pretty. Ну а “сбитие прицела“ иногда помогает лучше запомнить, отложить в памяти. Итого, в “календарном еженедельнике” ещё целый десяток и одна функция или лексем, их обозначающих или символов, короче слов в словаре. Далее, можно так и продолжать, включая разворачивание всего куста ссылок, с учетом того, что описания функций отсылают к другими функциями. Хотя очевидно, что стартовать надо с интерпретатора, а потом акцентировать редактор. Можно будет так и сделать “в следующем проходе“ по темам или в черновике нового сто страничного и актуализированного мануала.

С точки зрения полиморфизма, имееет ли смысл в таком количестве функций “вывода“ … кстати, где-то автор полиморфизм вкючает, а где-то нет. Можно предположить, что так было удобно, оправдано, например, с точки зрения, оптимизации самих вычислений, а не синтаксиса. Возможно. Хотя, при любых аргументах, работают те же префиксы и суффиксы … Короче, в этой уникальной, оригинальной, универсальной и даже со всех сторон продуманной архитектуре, ощущается “легкий хаос“ в синтаксисе. Что всегда объяснимо для “старых систем“, в которых постепенно исторически неизбежно накапливаются … что … не то что ошибки, а текущие решения, которые работают, а поэтому не требуют “трансформации“, особенно на фоне других перспективных и ещё не решенных проблем. Но и трансформации имеют приоритеты и если что-то переделывать,то чем раньше, тем лучше. Тем более, что это не требует какого-либо тестирования. Протсо надо быть в этой процедуре аккуратнее. Конечно, есть механиз переопределения. Но это чуть другое, как и алиасы.

P.S. А ещё, чтобы не забыть, отмечу по поводу термина “функция“. Традиционно, в математике, функция, прежде всего то, что обозначает результат отображения, было одно, что трансформируется в другое. так было и изначально в программировании, когда функцию надо было выделить от процедуры и использовать как аргумент или параметр для атрибутирования другого активного объекта. PicoLisp - абсолютно прагматичен и вне всяких “надуманных парадигм“, а поэтому может стать и эталоном в интерпретации самого себя, стать совершенным во всем, “как по содержанию, так и по форме”. Кстати, как описание системы может помочь в её развитии, без изменния её архитектуры?