print как тема

Авторская документация состоит из двух основных частей - туториала или мануала и референций. Вот с учебника или руководства можно начать исследование функциональности системы с точки зрения авторских приоритетов. И первой функцией после самого интепретатора является prin или целый набор функций, собственно, обзора самой системы … “некоторые функции для просмотра фрагментов данных и кода в работающей системе“ … Ну, а включая и параметр лексических аналогий акцентируем print, pp, pr, prBase64, prEval, pretty, prinl, println, printsp …
В списке ещё “затесалась” pre? для проверки, является ли “что-то“ префиксом “чего-то“, но это акцентирование обусловлено присутствием pretty. Ну а “сбитие прицела“ иногда помогает лучше запомнить, отложить в памяти. Итого, в “календарном еженедельнике” ещё целый десяток и одна функция или лексем, их обозначающих или символов, короче слов в словаре. Далее, можно так и продолжать, включая разворачивание всего куста ссылок, с учетом того, что описания функций отсылают к другими функциями. Хотя очевидно, что стартовать надо с интерпретатора, а потом акцентировать редактор. Можно будет так и сделать “в следующем проходе“ по темам или в черновике нового сто страничного и актуализированного мануала.
С точки зрения полиморфизма, имееет ли смысл в таком количестве функций “вывода“ … кстати, где-то автор полиморфизм вкючает, а где-то нет. Можно предположить, что так было удобно, оправдано, например, с точки зрения, оптимизации самих вычислений, а не синтаксиса. Возможно. Хотя, при любых аргументах, работают те же префиксы и суффиксы … Короче, в этой уникальной, оригинальной, универсальной и даже со всех сторон продуманной архитектуре, ощущается “легкий хаос“ в синтаксисе. Что всегда объяснимо для “старых систем“, в которых постепенно исторически неизбежно накапливаются … что … не то что ошибки, а текущие решения, которые работают, а поэтому не требуют “трансформации“, особенно на фоне других перспективных и ещё не решенных проблем. Но и трансформации имеют приоритеты и если что-то переделывать,то чем раньше, тем лучше. Тем более, что это не требует какого-либо тестирования. Протсо надо быть в этой процедуре аккуратнее. Конечно, есть механиз переопределения. Но это чуть другое, как и алиасы.
P.S. А ещё, чтобы не забыть, отмечу по поводу термина “функция“. Традиционно, в математике, функция, прежде всего то, что обозначает результат отображения, было одно, что трансформируется в другое. так было и изначально в программировании, когда функцию надо было выделить от процедуры и использовать как аргумент или параметр для атрибутирования другого активного объекта. PicoLisp - абсолютно прагматичен и вне всяких “надуманных парадигм“, а поэтому может стать и эталоном в интерпретации самого себя, стать совершенным во всем, “как по содержанию, так и по форме”. Кстати, как описание системы может помочь в её развитии, без изменния её архитектуры?
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
Всегда чему-то учусь!