DRAKON.SU

Нет, просто вы не до сих пор не заметили, что пытаясь описать текстовый формат языка Дракон, Владимир Даниелович фактически описывает язык программирования (заодно подгоняя его под C). Всё ещё не видите лес за деревьями? Как думаете, эти вайлы и ифы в описании - это язык программирования или формат? Есть ли между ними противоречие? Или когда вайлы и ифы относятся к С - это язык программирования, а когда к текстовому формату Дракон - то формат?

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

> Как думаете, эти вайлы и ифы в описании - это язык программирования или формат?

Я думаю что это глупость.

Думайте тщательней.

Исправленный вариант. См. пункт 16

Дракон- это графический язык, отсюда и танцуем.

Визуальная часть программы состоит из всяких фигур в виде ромбов, прямоугольников и прочих кружочков. У каждой фигуры есть входные и выходные точки подключения. Фигура с точками - это семантическая составляющая, которая нужна для генерации кода. По-сути, это уже готовый граф, который строит синтаксический анализатор любого языка программирования. Кодогенератор, обходя граф, порождает исполняемый код. По этому графу может быть отображена исходная программа.

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

Текст программы на Драконе мог бы выглядеть примерно так:

Action
{
...
"Ромб_1"{ "i>2" "Да=М1" "Нет=М2" };
...
}

Visual
{
...
"Ромб_1", "x=159", "y=223";
"М1"{ [23;74], [72; 54], [445; 32], [343; 129] };
...
}

Замечу, что две ипостаси связи между, например, выходом условия М1 и входами других фигур, для которых М1 является входом, строго разделены на семантическую и визуальную.

Смысл отсутствует.
Смотрите, осваивайте и используйте ИС Дракон.

О кодогенерации. ИМХО, тут Дракон полетел куда-то далеко и не туда, куда нужно.

Мы рисуем программу на драконе, какая, нафиг, разница через какой промежуточный язык будет получен исполняемый код? ИМХО, ошибка при создании Дракона в отсутствии платформы для его исполнения. Я ведь потому и говорю, что алгоритмы на Драконе висят в воздухе, не привязанные ни к чему.

Например, есть ПЛК. У него есть дискретные входы, дискретные выходы, аналоговые входы, аналоговые выходы. К каждому входу и выходу подключен провод, по которому сигнал приходит в ПЛК или уходит из него. Более того (и это главное!), каждый вход или выход является переменной, над которой по заданным алгоритмам выполняются операции. Отсюда следует, что в программе на Драконе должно быть описание объектов, над которыми выполняются действия.

Имея описание объектов, список операций в виде фигур, для каждой из которых указано откуда брать значения и куда их складывать, можно генерировать код. Замечу, что все эти ромбики-кружочки, по-сути, представляют собой функциональные блоки (или "чёрные ящики", кому как привычней), имеющие входы и выходы, к которым привязаны именованные значения, являющиеся внутренними переменными. Да, эти М1 и М2 можно не использовать при генерации кода, но лучше оставить, ибо имея список этих переменных, можно, например, в динамике, прямо на диаграмме, показывать какая ветвь у ромба активна, "Да" или "Нет". Для выражений типа "i>2" показывать текущее значение, для чего необходим протокол передачи списка наблюдаемых переменных и их значений. Более того, например, язык Си позволяет вставлять в исполняемый номера строк, выполняемых в данный момент, на основании чего можно отслеживать и выделять ромб-прямоугольник-кружок, код которого сейчас выполняется.

И ещё необходимы два механизма: первый собирает информацию о сигналах из внешнего мира и на их основании устанавливает текущие значения для входных объектов, второй- переносит сформированные значения во внешний мир.

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

Важные критические замечания участника tonyk

1. Дракон- это графический язык программирования. А где графическая отладка? Я её не заметил. Ведь если вы можете по графической схеме построить исполняемый код, так постройте его для виртуальной Дракон-машины, чтобы можно было его тут же, в среде программирования, запустить и отладить.

2. в процессе отладки значения всех переменных должны отображаться прямо на схеме программы.

3. необходимо иметь возможность отладки и на "железном" контроллере, наблюдая значения переменных и имея возможность их изменять.

4. Как это выглядит и работает, можно посмотреть в любой среде разработки для ПЛК на примере графических языков FBD, LD, SFC.

5. Будь симулятор и графическая отладка, Дракон можно было бы встраивать в МК, получая полноценный ПЛК.

6. Ребята, вы в тупике. И будете в нём до тех пор, пока не появится текстовый формат языка Дракона.

7. нужен формат обмена отладочной информацией между средой программирования и исполнения.

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

9. Пока сделайте главное, дайте описание текстового формата Дракона в БНФ.

10. Мне нравится концепция Дракона, будь у Дракона то, о чём я написал (текстовый формат, протокол обмена с рантаймом и т.п.), с удовольствием занялся бы переносом его на ПЛК.

11. на Дракон вообще не предусмотрена работа с периферией контроллеров.

12. Нет даже упоминаний о низкоуровневой работе с регистрами периферии целевого контроллера, нет понятия "функциональный блок".

13. Не заметил возможности написания фрагментов программы на языках низкого уровня, например, С/С++ или ассемблер.

14. Каждый новый редактор Дракона хранит файлы в своём формате, поэтому для каждого нового редактора его автор создаёт свой формат. В итоге всё, что было создано ранее в других редакторах невозможно открыть в новом. Сравните ситуацию с текстами программ на Паскале и Си, которые даже сегодня, по прошествии десятков лет после их написания, можно скомпилировать и запустить на выполнение.

15. Как проверить правильность работы нарисованной Дракон-схемы? Сейчас- никак. Сравните со средами разработки для ПЛК, в которых всегда есть симулятор, поэтому даже без загрузки программы в реальный ПЛК можно проверить работу алгоритма. Я уже не говорю о том, что в симуляторе обязательно есть отладка, чем даже не пахнет в Драконе. Парадокс: Дракон декларируется как язык создания надёжных алгоритмов, но сам не имеет средств для проверки правильности этих алгоритмов. Я 70-80% времени при отладке трачу на работу в симуляторе, а оставшееся время на работу с реальным "железом" и то, в основном, на подбор таймингов.

16. Толку от красивой Дракон-схемы, которую нельзя проверить без загрузки на исполнение на реальном "железе", будет чуть больше нуля, поэтому, ИМХО, нужна проверка правильности её работы.

17. я не увидел в Дракон-редактора явно функции создания модулей программы и многолистовых схем. Про отсутствие нормальной печати с разбивкой на листы, на которых автоматически расставлены межлистовые ссылки, уже писал тут: viewtopic.php?f=62&t=6996&start=160.

18. цель- это получить Си-файл с привязкой к Дракон-схеме и научиться синхронно "шагать" по Дракон-схеме и Си-файлу. Научитесь - получите основу для создания полноценной DragonIDE, нет - будет очередная рисовалка картинок с функцией генерации никому не нужного Си-файла.

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

1. Текстовый как бы вариант схемы - это бессмыслица со всех сторон. Он должен был бы выглядеть так:

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

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

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

Нужен..., а кому и зачем?
Что Вы будет с этим делать?
Пускай, Вы сами придумайте для себя.

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

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

Я умышленно не использовал такую запись:

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

Ответы на все эти вопросы я давал выше, и кому нужен, и для чего, и что с этим делать. Или не читали, или не поняли.

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

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

Вы не разобрались в ситуации и отвечаете совершенно невпопад. Я на форуме начал писать в основном потому, что Владимир Даниелович попросил меня составить список недостатков языка ДРАКОН для его статьи на habr. И теперь я пишу в этой теме, потому что он попросил прокомментировать предложенный черновик формата, так как я упоминал о такой вещи ранее.

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

Comdiv, спасибо. Вот исправленный вариант

Но это же не исправленный вариант - } после операторы1 преждевременна, она должна быть перед последним else. m1 не нужна на схеме, так как она имеет чисто техническое значение в текстовом формате.

Кроме того, я подумал о неоднозначности в текстовом представлении при использовании goto. Следующий вариант, наверно, будет лучше, так как подчёркивает переход вперёд, а не псевдо-возврат назад, как в первом.



Также, на мой взгляд, комментарий 2 в представленном виде только запутывает. Если не получается сделать нормальный, то лучше просто убрать.

И Вы ничего не ответили про 12-15, которые составлены по другим правилам, что усложняет разбор.

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

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

2. Простота разбора.
2.1. для независимого кода, потенциально создаваемого с нуля.
2.2. при использовании популярных библиотек и форматов.
3. Переносимость

4. Для описания неформальных алгоритмов.
5. Для описания исполняемого кода.
6. Для генерации в исполняемый код.
6.1 Генерация текста, близкого к тому, что мог бы написать человек, для создания отчуждаемых текстов.

7. С возможностью писать и понимать код напрямую из формата хранения. Это один из популярных способов создания схем, предпочтительный для многих разработчиков.
8.1. Наилучший для понятности синтаксис.
8.2. Максимальное соответствие одному из выбранных для генерации языков(не отменяет связь с другими языками). В идеале сохраняемая схема могла бы напрямую быть частью исходного кода без дополнительной генерации или даже извлекаться для отображения из независимо написанного исходного кода.

9. Для автоматически расставляемых элементов отображаемых схем
10. Для редакторов с тонкой настройкой внешнего вида