Geniepro писал(а):
Там же вроде как не всё так просто...
Паронджанов писал, что там две части -- императивная, которая выражается дракон-схемами (и которую легко отранслировать в машкод или Оберон-исходник), и декларативная, зависящая от конкретной предметной области. Эту часть уже специально под конкретную задачу нужно делать, левый разработчик вряд ли хорошо это сделает...
Уважаемый Geniepro!
Вы меня не совсем точно процитировали. Ваша фраза
"декларативная, зависящая от конкретной предметной области. Эту часть уже специально под конкретную задачу нужно делать..." нуждается в уточнении.
Следует различать два случая.
Случай 1. Создание ГИБРИДНОГО языка. При этом процедурная часть какого-либо существующего языка (например, Паскаль, Модула-2, Оберон, Си, Питон, VB и т.д.) заменяется на графику Дракона.
А декларативная часть указанного существующего языка ОСТАЕТСЯ БЕЗ ИЗМЕНЕНИЙ. Точнее, она вполне может остаться без изменений.
В результате этой работы получается гибридный язык (например, Дракон-Паскаль, Дракон-Модула, Дракон-Оберон, Дракон-Си, Дракон-Питон, Дракон-VB и т.д.).
Декларативную часть гибридного языка не надо изобретать. Ее следует заимствовать из того самого языка который подвергается "драконизации".
В этом случае Ваша фраза
"Эту часть уже специально под конкретную задачу нужно делать..."
НЕВЕРНА.
Почему неверна? Потому что набор задач полностью определяется существующим языком (например, Паскаль, Модула-2, Оберон, Си, Питон, VB и т.д.).
Случай 2. Создание НОВЫХ языков (например, Дракон1, Дракон2, Дракон3 и т.д.).
Тут ситуация иная. В этом случае надо определить, для каких целей (задач) создается новый язык. Исходя из этих задач, действительно (и тут Вы правы), надо заново определить, как следует строить декларативную часть.
P.S. По сути дела, я подробно описал ту мысль, которую в краткой форме уже изложил Ярослав Романченко
viewtopic.php?p=18374#p18374