DRAKON.SU

Задумался над вопросом создания "альтернативной" IDE для дракона. На первый взгляд использование в качестве основы одной из RCP (н-р, netbeans или eclipse) должно позволить реализовать IDE достаточно быстро.

Неспеша размышляю над различными аспектами будущей системы

Вопрос номер один - формат хранения схем.

Самое простое решение использовать бинарный формат (вплоть до сериализации схемы ), но оно мне не нравится, т.к.:
1) Схемы могут храниться в cvs. Было бы очень хорошо если бы стандартные diff/merge-инструменты выдавали осмысленную информацию. С бинарным форматом достичь такого не получится.
2) Хочется иметь возможность редактировать текстовое представление схемы "вручную", без использования IDE. Можно представить достаточно много ситуаций, когда "рефакторинг" схемы проще/быстрее осуществить над текстом, чем в "визуальном" режиме.
3) Спецификация бинарного формата обычно сложнее, чем текстового. Это осложняет реализацию и поиск "багов".

Есть какие-нибудь идеи на этот счёт? Может быть текстовое представление и не нужно?

Думал об xml-ном описание. С одной стороны упрощается разбор, с другой - страдает читаемость и модифицируемость "руками"...

-----

Забыл упомянуть один момент.
Текстовое представление может служить для представления:
а) программы на "псевдо" языке, где есть только управляющие конструкции.
Н-р:

б) описания графа (вариация на тему входного файла для graphviz'a).

(б) - проще реализовать, но вряд ли такое предсталение будет пригодно для ручной правки и diff/merge...

Для diff/merge обязательно надо текст. По формату - ini-файла достаточно.

А что такое формат "ini-файла"?
Можешь привести текст описывающий, какую-нибудь простую дракон-схему?

Честно предупрежу о двух вещах:

1) Нормальный редактор будет сделан. Загадывать сроки не буду, но вопрос там чисто в рутинной реализации (на подходящей мат. модели никаких концепт. проблем нет), которая уже ведётся у нас.
2) Соваться с кавалерийским наскоком не советую, разве что заняться нечем Там без подходящей модели делать нечего. На программёрском уровне не выйдет.

"У нас" - это где? Речь о редакторе Тышова или есть ещё какой-то проект (доселе скрытый от общественности)?

И еще вопрос вдогонку. Где-нибудь можно найти простой редактор блок-схем на ББ(и чтоб посмотреть, как-таки оно в ББ можно...)?

Извиняюсь, если неясно выразился. Когда я говорю о каких-либо разработках, то речь об организации которую представляю - ООО "Метасистемы", http://metasystems.ru.
OberonCore является интернет-ресурсом, а не коллективом. Поэтому говорить про тех многих людей, которые здесь представляют свои проекты, "у нас" мы не можем.

Что именно "можно"? Схемки рисовать?

Вообще, посмотрите что-то в zinnamturm.eu.

Не нашёл упоминаний о драконе на вышеозначенном сайте...

Какая-нибудь информация в открытом доступе о текущих достижениях и/или планах вокруг дракона имеется (может быть хотя бы пара скриншотов)?

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

На мой взгляд, львиную доля труда, который придётся потратить на дракон ide, съест разработка эргономичного UI и связанной с ним инфраструктуры. Поднять это дело с "нуля" - я бы не взялся (особенно учитывая, что времени свободного очень-очень мало). Однако, беглый осмотр возможностей существующих RCP вселяет оптимизм.

Развенчаете что-нибудь из моих заблуждений?

Речь о топологии Дракон-схем. Описание в терминах "пересадка-заземление лианы" не является достаточно формальным, чтобы без проблем реализовываться. Если не хочется играться с уймой частных случаев.
Я просто описываю ситуацию, грабли. И говорю о том факте, что редактором занимаются.
А дальше уже пусть уважаемые коллеги решают, начинать - не начинать.
Ничего другого в виду не имелось.

Запись маршрутов на уровне примитива и ветки силуэта нужно сделать структурной. Без меток.
Правила Дракона гарантируют, что маршруты переходов будут либо обособленными, либо вложенными.
Добавим правило для "псевдоязыка": маршруты от структурной конструкции(макроиконы), ведущие к точкам объединения с другими маршрутами, маркировать явной передачей управления.

Маркировка может производится с помощью следующего набора:
Вариант 1

join - соединение(начало)

inner join - внутренее соединение(продолжить - простое соединение с существующим маршрутом)

return join - обратное соединение(петля цикла, оканчивающаяся стрелкой)

end join - конец соединения

Вариант 2

path - маршрут(начало)

inner path - внутренний маршрут(продолжить)

return path - обратный маршрут

end path - конец маршрута

Возможны структурные конструкции(по ходу алгоритма) :

JOIN

...

INNER JOIN

...

END JOIN

и

RETURN JOIN

...

INNER JOIN

...

JOIN

Тогда для Дракон-схемы можно будет строить полноценное AST. В принципе, выражение RETURN JOIN - лишнее и добавлено в набор только для явного обозначения места соединения маршрута с петлёй цикла. Исключительно для облегчения понимания человеком. Если мы откажемся от чтения линейной текстовой записи Дракон-схем, то достаточно использовать END JOIN вместо RETURN JOIN.

p.s.:Не нравится в этих вариантах наличие "end" - чем бы заменить, чтобы не совпадало с иконой "Конец". Может быть JOINED?
p.s.2:Куча скобок не впечатляет, хотя разбирать-то их преимущественно компу
p.s.3:Английский - чтобы сразу в глаза бросалось, где переходы.

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

Немножко подрихтовал код в предыдущем сообщении. В основном, из сображений, что "Развилка" может быть однозначно представлена "Переключателем" с вариантами "Да" и "Нет"Циклы (обычный, переключающий, для, ждать) однозначно представимы на основе словарей, приведённых ниже. Т.е., рисуем привычными for, if и case, а храним и отдаём транслятору - только с переключателями.
Базовый словарь для линейной текстовой записи может выглядеть так:

Остаются вопросы с расширенным набором икон, заточенных под предметную область:
а. таймер
б. параллельный процесс
в. период
г. ввод
д. вывод
...
Как вариант - могут создаваться в любом количестве в виде предметных словарей на базе "Вставки" и "Действия". В основном - для того, чтобы не очень криво идентифицировать графический образ иконы и иметь возможность "расширения" транслятора.
Обсудим?

Поддерживаю использования лисповских S-выражений (sexp).
Я вот тоже тут подумываю в одном проекте хранить древовидные структуры данных в таком формате...