new - Symbol Function

В новый день нового года напрашивается начать с Symbol Function - new, тем более, она первая и в неалфавитной классификации самого автора. Конструктор объекта … при указании параметров, в определенную базу данных (внешних символов). Детали можно посмотреть по ссылке, где сразу можно увидеть и тот же символ с суффиксом - new! - функция-обертка транзацкии для new. По сути мы все конструируем и такая спецификация конструктора явно по аналогии с общепринятой синтаксической практикой ООП. Разговор о разнице между прототипированными объектами и классами - отдельный, в системе помимо традиционного “вертикального“ наследования введено, так называемое, “горизонтальное“ с возможностью “тонкого“ изменения поведения, но об этом в другой раз в контексте соответствующих конструкторов. Здесь же акцентируюсь на синтаксисе, в принципе. Некоторые общие рассуждения об общем формате.

Автор в первой версии системы использовал аппликативную форму записи типа Форта, но утверждает, что “скобки“ оказались практичнее. В приниципе, трудно отказаться от скобок на практике и все их, так или иначе, используют, размечая “списки“. Используют и префиксы с суффиксами для спецификации символов. То есть эти синтаксические приемы имеют место везде и вопрос только в том, насколько аккуратно и последовательно. И не теряется ли возможность переименования и настройки пользовательского синтаксиса. Есть направление расширяемого языка (синтаксиса) XL, попытка сразу конструировать систему без синтаксиса для контруирования синтаксиса. В идеале это, конечно, невозможно и базовый синтаксис неизбежен, тем не менее, есть попытки конкретной реализации, например, проект Ring. И это тоже отдельная тема разговора, а здесь, хотелось бы вернуться к общим принципам - использования скобок, их спецификации и использования префиксов и суффиксов для символов.

В формате ASON, как более “функциональном“, чем JSON и “более оптимальном”, чем YAML, во-первых скобки не используюся “на первом уровне”, действительно, они есть по умолчанию и тогда нет необходимости в таких конструкция типа (bye), если можно просто bye. Можно использовать разные типы скобок для оцениваемых и неоцениваемых выражений, круглые и квадратные. И так далее … для объектов, XHTML-разметки и вплоть до возможности именования скобок, как в XML. Короче, идея в том, чтобы не навыязывать пользователю, чуждую ему лексику с возможностью перенастривать её так, как кому нравится и кто к чему привык. И это было бы последовательно, в рамках приниципа минимализма. То же самое с префиксами и суффиксами, позволяющими не перегружать дополнительной лексикой. Но пока этот вопрос для всех открытый и остается только положиться на опыт авторов проектов. Никакое “голое теоретизирование“ без практической демонстрации здесь не поможет. В первую очередь, в расчет берется функциональная развитость самой системы, её архитектура, а потом уже синтаксис. Тем более для GUI, призванном свести эти проблемы к нулю и говорить и думать уже о современных стандартах для интерфейса, о котором, кстати, и думать как о “языке“ … или наоборот. Будем думать об этом дальше. Возможно о специальных парсерах и транспиляторах … Главным, в основе, всегда остается архитектура организация памяти! А в проекте PicoLisp она позволяет память плотно использовать без перформатирования и с тривиальной сборкой мусора. Но это тоже отдельная тема …