OberonCore

Сначала соглашусь со всем, что выше написал Валерий Лаптев.

Я убежден, что требование совместимости с морально устаревшим текстовым представлением - неоправданные оковы для разработки и последующего развития семантического редактора. В нем не должно быть парсера с ЯВУ. Разработка трансляторов с/на ЯВУ для семантического редактора - отдельная и второстепенная задача, причем Оберон тут не выглядит фаворитом в сравнении с C++, Java и другими языками, на которых написаны большие библиотеки. Внутреннее представление во время работы семантического редактора - абстрактное семантическое дерево и таблица символов, а хранение кода на диске - параллельно в формате XML (для возможной последующей обработки в семантическом редакторе) и в виде исполнимого кода. Формат XML лучше бинарного файла из соображений обратной совместимости.



Оберон - всё-таки язык для текстового представления программы. Графическое представление программы существенно изменит язык. Вспомните, что Вирт вносил изменения в свои языки по гораздо менее весомым причинам. Есть и другие причины для разработки нового языка:
1. Прогресс не стоит на месте (параллельные вычисления, изменения системы команд процессоров и т.д.)
2. Имеющийся компилятор - проприетарный продукт
3. Специфические учебные цели
4. Необходимость учесть коммерческий провал линии оберонов и предотвратить такое развитие событий для семантического редактора
5. Недоступность некоторых информационных технологий из программ, написанных на Оберонах (недостаточная интегрированность)
6. Необходимость устранить барьер между языком и стандартной библиотекой

Сергей, правильно ли я понял (?), что Ваш проект в целом состоит из трёх частей:

1. Специальный диалект какого-либо традиционного языка программирования (на Вашем сайте в качестве такового упоминается Оберон).
2. Специальный компилятор с указанного диалекта, совместимый с семантическим редактором и, возможно, встроенный в него.
3. Собственно семантический редактор.

Я не планирую в ближайшем будущем делать семантический редактор. Участвую в обсуждении потому что тема мне показалась интересной.

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

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

А я наоборот, сразу начинаю рассматривать с точки зрения устройства "кишков" . А интерфейс для меня - дело десятое. Он конечно важен, но если что, его можно будет вообще переделать. Это, так сказать, только фасад.

Двоичный файл тоже может быть удобен с точки зрения обратной совместимости, необходимо лишь придумать соответствующий формат.

Чем xml представление и необходимость его распознавания радикально лучше текстового представления программы и необходимость его распознавания? Тем что есть сторонние XML-парсеры, и вообще это промышленный стандарт?

С точки зрения кишков. Внутреннее представление проги - статическая семантическая модель. Эта модель должна, с одной стороны, отражать статическую структуру проги. С другой стороны должна быть удобна для:
1. анализа и оценивания на предмет вычисления разнообразных метрик. Это необходимо в обучающей среде, поскольку она должна оценивать работу студента. Простое выполнение на тестовых данных и сравнение результатов с эталоном - недостаточно.
2. статическая модель может непосредственно интерпретироваться в обучающей среде.
3. Из статической модели легко получить разные представления программы.
Вот о статической модели сейчас и размышляем. А также - в чем реализовать. Первый вариант - БлэкБокс. Второй - студия 2010 на додиезе. Третий - сразу в обеих системах и посмотреть-сравнить.

Вроде бы ветер прогресса дует именно в сторону XML. Я не специалист в XML, но читал, что сериализация объектов Java в формате XML теперь даже быстрее, чем в бинарном формате. А гибкость (и, следовательно, обратная совместимость) XML для меня вне сомнений. Что касается большего объема кода на жестком диске, то это как раз тот случай, когда объем совершенно не важен. Речь ведь идет только о коде разрабатываемой программы.

Любая из реализаций XML-парсеров тормозная и перегруженная по определению. И с бинарным форматом она даже рядом не стояла. Даже в теории.

Berserker прав. Я как-то писал свой парсер по стандарту XML 1.0. На первый взгляд язык разметки достаточно простой, но это обманчивое впечатление. Взять хотя бы такую штуку как DTD, из-за которой я это дело бросил. Она есть даже в первой версии стандарта. При несоответствии документа указанному DTD парсер обязан выдать ошибку (well-formedness constraint). Если бы это было опцией, я бы ещё понял, но... если парсер этого не умеет, он не поддерживает XML 1.0.

Соответственно, для действительно эффективной работы нужно изобретать подмножества XML. Зачем? Будут ли они совместимы с чем-либо и до какой степени? К тому же в XML оверхед всегда получается ого-го какой - и по объёму данных, и по времени на их обработку и проверку ("все ли тэги правильно закрыты?" и т.п.). Чего стоит только требование (постоянно нарушаемое по очевидным причинам) данные всегда размещать внутри тэга, а не в параметрах. Хотите, чтобы внятно и читабельно было, используйте длинные идентификаторы, но будьте любезны писать полностью: <FirstDataPoint>1.0</FirstDataPoint>.

Представьте себе данные графика:
<X>1.0</X><Y>1.0</Y>
<X>2.0</X><Y>1.0</Y>
<X>3.0</X><Y>1.0</Y>
<X>4.0</X><Y>1.0</Y>
Мусора вдвое больше, чем, собственно, данных.

Чтобы этого избежать, начинают придумывать всякие фокусы с параметрами:
<GUIConfig name="TabBar" dragAndDrop="yes" drawTopBar="yes" drawInactiveTab="yes" reduce="yes" closeButton="no" doubleClick2Close="no" vertical="no" multiLine="yes" hide="no" />
<GUIConfig name="TabSetting" size="3" replaceBySpace="yes" />

Всё запихали в параметры, а по содержанию, собственно, XML-документа получили кучку пустых тэгов GUIConfig. А что в результате-то? А в результате тот же ini-файл и получили, только секции в строчку записаны, да всякие неугодные символы вынуждены были закодировать (типа &lt; или &quot;). А в ini-формате-то таких спецсимволов только один - перевод строки.
[TabBar]
dragAndDrop=yes
drawTopBar=yes
drawInactiveTab=yes
reduce=yes
closeButton=no
doubleClick2Close=no
vertical=no
multiLine=yes
hide=no

[TabSetting]
size=3
replaceBySpace=yes

XML - это формат для сферического экспорта данных в вакуум, но не для работы. Ну, и дань моде, конечно же.

Вот в пику обсуждения цитата из известной статьи с критикой XML:

Теоретические недостатки XML известны: медлительность парсера, большой объем документов и недостаточная читабельность для человека. Для нашего случая: - последние два недостатка не имеют значения. Первый недостаток (медлительность парсера) возможно имеет значение, но перевешивает ли он достоинства XML, и есть ли достойная альтернатива XML - это вопрос. К тому же, можно спроектировать семантический редактор таким образом, чтобы не приходилось обрабатывать большое количество объемных XML-документов одновременно, или чтобы такая обработка происходила в фоновом режиме и не задерживала работу программиста.

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

Вот, кстати, цитата из того же источника (http://newsletter.narod.ru/sql_pages/sql_jul_2005.htm): Отсюда видно, что каждый инструмент должен применяться к той задаче, для которой он пригоден. XML - для длительного хранения данных о деревьях (абстрактных синтаксических).

См. также http://pco.iis.nsk.su/ICP/Practice/dd8-6/node11.html
http://zonnoncompilerforjava.blogspot.com/

Вот, попробовал что-нибудь найти в интернете о представлении программ на Zonnon и оберонах в формате XML:



Кстати, я не считаю XML хорошим форматом для внутреннего представления программ в семантическом редакторе. Роль XML - сохранение исходного кода и данных на жестком диске.

TIFF.

Очень смешно

Я не имел в виду графический формат, я имел в виду, что у TIFF очень простая и гибкая структура. Я использовал его модификацию для хранения данных в одном из своих проектов. Там было типичное сохранение иерархической структуры объектов (то, для чего декларируется главная польза структурированности XML). При этом каждый объект сохраняет только свои собственные данные, полная инкапсуляция.

Формат прост до неприличия: <Tag: INTEGER><Size: INTEGER><Data: ARRAY Size OF BYTE>

Формат данных для своего поля Data в каждом из Tag'ов каждый объект определяет сам. Где-то это просто дамп памяти (например, ARRAY N OF RECORD X, Y: REAL END), где-то набор вложенных блоков Tag/Size/Data (при этом каждый объект имеет собственное "пространство имён" для Tag'ов). Если поле Tag не распознано, просто пропускаем Size байт в потоке и продолжаем обработку. Таким образом, старые версии программы могут читать файлы, созданные более поздними версиями, пропуская неизвестные Tag'и (хм.. выходит, я сам додумался до generic message bus на файловых потоках. Интересно).

Если интересны подробности, спрашивайте.

Спасибо!

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

Интуиция мне подсказывает, что единственной реальной альтернативой XML может быть какой-нибудь табличный или объектный формат хранения данных - вроде тех, что используются в СУБД или для сериализации объектов. Но он должен обладать такими достоинствами XML, как обратная совместимость (формат прост, и поэтому неизменен), расширяемость (добавление новых тегов), компактное представление деревьев, возможность хранить в одном файле/документе разнородные данные (деревья и таблицы, состоящие из записей, а также параметры, относящиеся к файлу/документу в целом, такие, как контрольная сумма, дата создания и код формата). Буду искать такой формат.

Посмотрите ещё конкурентов XML: JSON, YAML, SDL, ...

Comparison of data serialization formats

Тогда уж сразу ASN.1
Ну и thrift & google protobuf.

Я всё же склоняюсь к тому, что программный код из семантического редактора должен сохраняться на жестком диске не в текстовые файлы с XML или иной разметкой (и тем более не в форме текста на языке Оберон-*), а в базу данных, структура которой максимально приближена к структуре внутреннего представления программы. Деревья прекрасно сохраняются в табличной форме (одно из полей таблица - указатель на родетельский узел). Тогда такие проблемы, как разработка парсера и его "тормознутость", отпадают сами собой.

Выбор движка (библиотеки, встроенной СУБД) базы данных - это, конечно, сложный вопрос.

Хотелось бы знать, что по этому вопросу думает Валерий Лаптев. "Кишки" семантического редактора - его епархия.