Очередной Язычок

И снова от безделья появляются идеи написать очередной (да) язык. Оглядев LEAF, LOMO и o.t. для себя понял, что многие идеи хоть и звучат разумно, но выглядят при этом совершенно отвратительно.

Чего стоит хотя бы вызов процедур, обязательно указывать именование входного параметра это конечно хорошо, но во-первых, их не всегда помнишь, а во-вторых, конструкция получается очень сложной.

Call(x: 1, y <- my.y, res -> x)

Сложновато, как не крути. Получается, что порядок аргументов процедуры важен. Из этого вытекает необходимость в сигнатуре процедуры описывать всё именно так, как в Обероне PROCEDURE Call(x: INTEGER; IN y: INTEGER; OUT x: INTEGER), что конечно неплохо (в очередной раз удивляюсь продуманности Оберона), но не оставляет пространства для маневра. И еще в этой форме записи всего полшага остаётся для признания процедуры функцией, со всеми вытекающими последствиями.

И таких моментов много. Навигация внутри MAP требует постоянного разыменования значения. Так как цепочки селекторов я не реализовал, навигация требует ещё и кучи временных переменных.

Сами селекторы, как показал LOMO, тоже могут быть довольно нетривиальной сущностью. Тут проходит трудноуловимая грань между строгой и нестрогой типизацией, когда цепочки селекторов должны неявно разыменовывать значение. А это значит, что на каждом этапе разыменования внутри может оказаться UNDEF-значение или вообще примитивный тип.

Плюс к этому, сама идея разных языков с очень похожей (очень) системой типов намекает на то, что по факту это как будто один язык, мультипарадигменный, но при этом принципиально по-разному обращающийся с рантаймом и переменными. А ведь иногда действительно декларативный подход выглядел бы лучше и проще даже внутри полностью императивного кода. Но смешение парадигм это довольно опасная дорожка.

А тут ещё и язык шаблонов сам собой нарисовался. Простой способ описывать всякие объекты, произвольной природы, но при этом человекотипизированные (то есть человек понимает семантику чисто из описания, из текстового представления шаблона объекта). Интересные возможности открываются.

При этом недостатков в o.t. тоже хватает, например, необходимость закрывающего элемента, обозначающего конец содержимого. Никак я не придумал способ обнаруживать конец содержимого автоматически. Так же плохой идеей было переиспользование объектов. Точнее, идея хорошая, но по факту получилось слишком сложно, как в разборе, так и в понимании. А еще я не реализовал программирование внутри шаблонов, не осилил. Отсюда, в общем, и мысли о новом язычке, в котором, ну правда-правда, всё будет идеально продумано и реализовано.

Главное не перечитывать пост про жизненный цикл программы, а то можно до конца года так и сидеть, продумывая каждый этап.

В общем, пройдя по пути создания императивного языка, декларативного языка и языка разметки я снова оказался в начале пути.