Обсуждение

Бывают люди способные понять ваш вопрос :) Насчет различения синтаксиса и семантики установил для себя такое правило: синтаксис и семантика являются не столько завершенными содержательными терминами, сколько способами отношения к некоторому содержимому, обозначающие выбор класса метода работы с ним. Из широких названий наук их (с. и с.) можно уточнить до каких-нибудь операторов или модальностей, которые можно комбинировать в одном высказывании.

К понимающим вопрос и я сам отношусь :) Где найти тех, кто может на такие вопросы отвечать -- вот в чем проблема! Вот тут в комментах еще немного развития этой "лингвистической" ("языковой метафоры в системной инженерии") темы: http://ailev.livejournal.com/685455.html

> Что меня забавляет, так это смешивание абстрактного синтаксиса с семантикой вплоть до неразличения (типичные фразы типа "An abstract syntax tree reflects the semantic structure of a program" Ну оно не то чтобы совсем глупость, поскольку АСТ - это как и есть вход для семантического анализа. Т.е. в АСТ весь чистый синтаксис вырезан и оставлен лишь смыслоразличительный синтаксис, а это уже можно считать семантикой в сыром виде.

Я тоже синтаксис и семантику примерно так различаю. В классическом компиляторостроении собственно оно так и есть: лексика, синтаксис, семантика. Т.е. смысл в том, чтобы оперировать понятиями покомпактнее, а для этого есть система фильтров: на этапе лексического анализа абстрагируются от буковочек/циферок, на этапе синтаксического - от скобочек и запятых. А с другой стороны, то что для компилятора - синтаксический мусор, для человека имеет семантическое значение - комментарии к примеру. А в последнее время, комментарии не пустой звук и для различного рода тулзов, от Javadoc'а до design-by-contact и верификационных тулзов.

А зачем стандартизировать АСТ? Пока оно в основном нужно для внутреннего пользования в рамках компиляторов и тулзов. Стандарт будет лишь дополнительным обременением для разработчиков компиляторов/тулзов. Сразу скажу, что для комплексирования ДСЛ оно не удобно ибо сразу вносит ограничения на класс комплексируемых ДСЛей.

Комментарии -- это просто в явном виде прилепленные кусочки контекста. Контекст в лингвистике строго отделен от текста, но активно обсуждается. Так что с комментариями и "мусором" никаких чудес, все учтено могучим ураганом.

Вот и у меня такие же впечатления, но стандарт на AST позволил бы подключать алгоритмы разных поставщиков: одни люди бы писали разбор текста нового DSL в AST, другие описывали бы трансформации с этим текстом, третьи бы писали визуализации... Резоны я понять вполне могу. А для конкретной разработки IDE одной командой стандарт, конечно, только мешает. Стандарт нужен там, где есть много независимых лиц, принимающих разные решения.

Подобная штука потихоньку формируется вокруг тулзов и библиотек. Скажем есть такая библиотека Soot - она заточена на Джаву, и содержит инфраструктуру и различные алгоритмы анализа, оптимизации и преобразований байткода. Ее используют как в целях преподавания так и в других проектах - т.е. другие люди анализируют Джавовскую АСТ с помощью этой тулзы. Я тоже ее немного использовал, как это ни смешно, для создания компилятора ПХП - правда, я на этот проект забил на данный момент :). Просто было интересно поэкспериментировать со Скала, оптимизациями в приложении к ПХП.

Есть и другие библиотеки. Встречал чудную японскую библиотеку, не привязанную к Джава, с алгоритмами оптимизации и кодогенерации под разные платформы. Хорошая база для создания языков, если не охота к Жабе привязаться. Мне кажется, подобные библиотеки - это лучше чем стандарт, на данный момент, по крайней мере.

Вокруг AST много чего накручивается. Та же инфраструктура плагинов "моделирования" в Eclipse -- это ведь про то же самое. Тут проблема в терминологии: она не устоялась, поэтому за разными словами нередко скрывается одно и то же. "Модель и метамодель" в программировании означают часто то же, что "текст на языке и описание языка". То же про "байткод" и многое другое. Мне очень симпатично то, что делают с Ometa в VPRI. Там это как-то очень компактно и органично и полипарадигмально (не побоюсь этого слова ;)

Стандарт -- это когда можно выбрать среди разных библиотек, построенных вокруг этого стандарта. Или компоненты библиотек делают разные команды, которым такой стандарт нужен. Просто библиотеки не так интересны. Я уже высказывал эту мысль: ежели несколько независимых групп людей что-то разрабатывают такое, что результаты их разработки потом должны склеиваться, то стандарт нужен. Ежели одна группа разработала библиотеку, а другая только юзает эту библиотеку, то никакого стандарта не нужно. Стандарт есть там, где возможны разные реализации. Ежели есть одна библиотека, одна реализация, то стандарта не нужно.

А какая-нить центровая библиотека и может быть явным или неявным стандартом. В том же Эклипсе интегрируются разные тулзы завязанные на различные Эклипсовы АПИ. В контексте стандартизации АСТ, мне кажется что о стандартизации пока говорить рано. Т.е. народ сам кучкуется вокруг каких-то платформ или библиотек, которые и выступают де-факто стандартами.

В принципе, библиотека -- это стандарт на API. Привычный стандарт воспринимается как стандарт на данные. Мой пойнт в другом: стандарт -- это когда выполняются определенные условия его разработки и сопровождения (см., например, http://ru.wikipedia.org/wiki/%D0%9E%D1%82%D0%BA%D1%80%D1%8B%D1%82%D1%8B%D0%B9_%D1%81%D1%82%D0%B0%D0%BD%D0%B4%D0%B0%D1%80%D1%82). То есть "стандарт" относится к способу его разработки и сопровождения, а не к содержанию. А содержанием может быть что угодно -- текст библиотеки или фреймворка, API или веб-сервис, структура данных, набор объектов, текстовое описание чего-то абстрактного или конкретного и т.д.