DRAKON.SU

По ходу дела сообщаю...
Геннадий по моей просьбе высылал мне (для ознакомления с форматом .drt) исходный код первой версии Дракон-редактора, а я реализовал на его основе генератор кода Дракон -> Active Oberon.
При соответствующем оформлении Дракон-схемы, генерируется полноценный модуль, готовый к компиляции.
Исходную Дракон-схему и результирующий модуль прилагаю
Исходный код, естественно, я не раскрываю... поскольку Геннадий не прояснил условий на которых передал мне свой код. Видимо, лишь для ознакомительных целей...
Свой генератор могу в виде отдельного приложения, и опубликовать...
В новой версии редактора формат немного изменён, и схема уже не открывается. т.е. под новый формат уже требуется модификация...

Уважаемый Ярослав Романченко!

Я никогда не забуду, что именно Вы в четверг, 31 Мая 2007 года, в 15 часов 38 минут открыли на этом сайте самую первую тему по Дракону под названием
Визуальный язык программирования "Дракон"
Низкий Вам поклон.

И сегодня Вы открываете для всех нас новое направление исследований. Большое спасибо.

Теперь о главном. Рискуя ошибиться, хочу сказать, как я понимаю Вашу фразу

"При соответствующем оформлении Дракон-схемы генерируется полноценный модуль, готовый к компиляции".

Я понимаю это так. Вы создали не только генератор кода. Кроме того, Вы создали новый язык.
В самом деле, Дракон - это недоопределенный язык. Или, по терминологии Виктора Николаевича Касьянова, язык полипрограммирования.

Чтобы создать генератор кода Дракон -> Active Oberon, язык Дракон надо доопределить. Именно это Вы и сделали. Вы превратили язык слепышей в полноценный язык. Вы превратили язык полипрограммирования в настоящий язык программирования.

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

Созданный Вами новый язык (условно назову его Дракон-Оберон) Вы в явном виде не обозначили. Но дали четкое указание словами "При соответствующем оформлении Дракон-схемы".

Что значат слова "При соответствующем оформлении Дракон-схемы"?
Я понимаю эти слова в том смысле, что
Вы создали новый язык Дракон-Оберон.

Обращаюсь к Вам и ко всем участникам дискуссии с вопросом: правильно ли я понял суть происшедшего события? Если нет, прошу меня поправить.

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

Если говорить упрощенно, я понимаю это описание как совокупность правил, указывающих, в частности, КАКИМ ОБРАЗОМ пустые иконы Дракона следует заполнять текстом. И, кроме этого что-то еще.

Прошу высказать свое мнение по этому вопросу (по вопросу о необходимости иметь строгое описание нового языка и о смежных вопросах).

Обращаюсь к модератору с вопросом. Может быть, вопрос поднятый Ярославом Романченко, заслуживает выделения в отдельную тему?

Основные особенности "оформления" конечно касаются декларативой части, отсутствующей в Драконе.
На первых порах пришлось "приспособить" под неё блок "кометнарий", с разделением соответсвующих секций, собственно: коментариев, импорта, констант, типов и переменных. принадлежность той или инной секции определяется первым считанным из блока элементом, соответственно (*, IMPORT, CONST, TYPE и VAR.
Дело в том что, содержимое некоторых секций необходимо не только как справочная информация, а должно быть доступно и для модификации в процессе генерации кода.
Возможно более удачное решение - оформлять декларативную часть в табличной форме.
В TYPE секции даются типы и "пустышки" деклараций объектов (без методов и тел).
Каждая отдельная схема рассматривается как эквивалент процедуры в Обероне. При этом в Обероне можно рассматривать в качестве процедур ещё и тела модуля и объектов (после слова BEGIN) и нужно как-то различать процедуры модуля от процедур-методов объектов.
Было решено:
1. Тело модуля оформлять в виде схемы, в заголовок которой вписывается слово BEGIN
2. Префиксовать заголовки схем относящихся к методам объектов именами этих объектов. т.е. Object.Proc1, Object.BEGIN. Как видите, тело объекта тоже не забыли
3. Все остальные схемы соответствуют процедурам модуля.

Ознакомился с приложением. Поздравляю, Вы достигли замечательных результатов. Интересное использование ДРАКОН-схем. Разрешите поделиться первым впечатлением.

Создана новая форма представления программного кода: 2-х мерное, с заменой маршрутных операторов програмного языка в графику ДРАКОНА, распределением декларативных и командных операторов програмного языка по иконам.
Создана модель отображения графического ДРАКОН-листа в текст модуля программного языка.

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

Непонятно, что происходило со схемой силуэт. Адреса не соответствуют веткам, но при этом расставлены признаки веточных циклов, в редакторе это невозможно сделать.

Язык используется ограничено: нет соседних икон "Действие", все сведено в 1; нет икон "Вставка", используются вызова процедур в тексте икон "Действие", нет объединения линий, не использовался перенос лиан (как реализовать в программном коде).

В программном коде используется оператор AWAIT, если я правильно понимаю - взаимодействие параллельных процессов. Средства языка ДРАКОН - икона "Параллельный процесс" не используется.

Данное использование языка ДРАКОН представляет большой интерес и может найти широкое применение.

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


Я позволил себе внести небольшие модификации в способ отображения икон "Ветка" и "Адрес".


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


Да, пока используется немного ограниченное подмножество икон. В дальнейшем это всё конечно можно использовать

т.е. в варианте с моими изменениями адреса отображаются корректно

Уважаемый Ярослав Романченко!

Жизнеспособность любого начинания зависит от того, КАК ОНО ВЛИЯЕТ НА ПРОИЗВОДИТЕЛЬНОСТЬ ТРУДА. Если производительность труда увеличивается, начинание будет жить и развиваться. Если производительность не растет или даже уменьшается, начинание не получит распространения и отомрет.

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

Проще говоря, позволит ли Ваш Дракон-Оберон повысить производительность труда? Если да, на сколько процентов?

Я понимаю, что забегаю вперед. И что ответить на мой вопрос очень трудно. Но, может быть, у Вас есть какое-либо мнение по этому вопросу? Если есть, может быть, вы сочтете возможным его высказать?

Ярослав,

по поводу генерации из "полной топологии".

Ну, по поводу веток уже говорили - это конечный автомат, т.е. LOOP-CASE.

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

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

Процентов пожалуй не назову. По-моему самая сильная штука в ДРАКОНе это схема силуэт. Схемы "примитив" ввиду простоты так и "напрашиваются" на реализацию в текстовой форме, что видимо и предпочтительнее
Схема же "силуэт" может значительно ускорить написание программы. И что самое интересное, силуэт преобразованный в текст становится практически нечитаемым
Вот, ещё до прочтения Вашей книги я наткнулся на статью http://www.codenet.ru/progr/alg/algoritm.php Там тоже изложен довольно интересный способ устранения сложности алгоритмов, и в результате тоже получается автомат

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


1. Я согласен, что силуэт — главное достоинство Дракона. Скажу больше. Силуэт — его ЕДИНСТВЕННОЕ достоинство.

2. Примитив не в счет, так как его вообще не следует использовать (почти).

3. Алгоритм (или программу) я рассматриваю как последовательную декомпозицию силуэтов. В том смысле, что каждый силуэт может содержать много вставок, каждая из которых раскрывается как силуэт.
Примитивы при этом не используются (совсем или почти совсем).

4. Тем не менее, полностью отказываться от понятия «примитив» не следует по двум причинам.

5. Первая причина — педагогическая. Примитив — это прообраз (зародыш) ветки. Основные понятия и правила Дракона удобно объяснять на самой простой модели. То есть на примитиве. И только после этого переходить к рассказу о силуэте.

6. Вторая причина — необходимость описания «мелких огрызков». Откуда берутся "мелкие огрызки"? В процессе декомпозиции силуэта может случиться (очень редко), что какая-нибудь вставка окажется очень простой, элементарной. Настолько простой, что ее неудобно представлять в виде силуэта. Такую вставку можно назвать «мелким огрызком». Вот в этом (исключительном) случае полезно использовать примитив.

7. Добавлю еще одну мысль.
Ни в коем случае нельзя представлять программу как систему примитивов.
Потому что в этом случае НЕВОЗМОЖНО БЫСТРО УВИДЕТЬ ГЛАЗАМИ, как эти примитивы логически связаны между собой. Чтобы понять эту связь, нужен трудоемкий мыслительный анализ, который требует усилий, отнимает время и снижает производительность труда.

8. Систему примитивов всегда можно превратить в силуэт. При этом каждый примитив превращается в ветку силуэта. (Иногда часть примитивов превращается в ветки силуэта более низкого уровня на лестнице декомпозиции).

Итак, публикую транслятор
Тестовая ДРАКОН-схема прилагается (с испраленными надписями в иконах "Адрес").
Какие будут предложения по названию такой тулзы?
Deuterium Oxide не слишком термоядерно?

Уважаемый Ярослав Романченко!

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

Вот, что вырисовывается применительно к системе A2 и Активному Оберону.
Всё укладывается в табличную форму, и без проблем может быть проверено на целостность и корректность данных.
Типы и объекты приходится разносить в разные таблицы, поскольку объекты -- сложные составные типы.
С объектами получается что-то вроде древовидной структуры...

Дополнительно надо-бы добавить поле признака экспортируемости для костант, типов, объектов и их полей, переменных.

Вы показали 5 типов таблиц. Это полный список типов таблиц? Или это только примеры типов таблиц?
Если это только примеры типов таблиц, то сколько всего типов таблиц?

Пожалуйста, добавьте "поле признака экспортируемости" кудо надо. И покажите (если нетрудно) все типы таблиц в окончательном виде, чтобы их можно было обсудить.

Да, таблиц стало уже на одну больше. Записи забыл. С ними почти то-же что и с объектами, с небольшими отличиями.
И у объектов/записей дерево чуть глубже...

Хе-хе : ) А где <length> для "ARRAY <length> OF ... Flag"?

В принципе, саму length можно в качестве флага и использовать...
0 - динамический массив. Автоматом должен устанавливаться флаг "POINTER TO ..."
1 - не уверен имеет ли такое смысл , но 1 и выше это значит флаг установлен.

Уважаемый Ярослав Романченко!

У меня еще одна просьба. Вы два раза показали примеры таблиц. Между ними есть существенная формальная разница.
Таблицы, показанные 1-й раз, я условно назову СТАНДАРТНЫМИ.
Таблицы, показанные 2-й раз, я условно назову НЕСТАНДАРТНЫМИ.

Под стандартизацией я понимаю тот факт, что все таблицы, показанные 1-й раз, делятся на столбцы, причем столбцы имеют НЕИЗМЕННЫЕ названия.
В таблицах, показанных во 2-й раз, это условие не соблюдается.

Мой вопрос состоит в следующем. Можно ли более полные и продуманные таблицы, показанные 2-й раз, СТАНДАРТИЗОВАТЬ? Быть может за счет каких-то искусственных или хитроумных приемов? Или это в принципе невозможно? Если это возможно, я прошу показать весь набор таблиц в стандартизованной форме (если это Вас не очень затруднит).

Я бы не называл таблицы, показанные 1-й раз СТАНДАРТНЫМИ. Они скорее не совсем корректны, поскольку не содержат всей необходимой информации.
Формат таблиц импорта, констант, типов и переменных довольно прост. Таблицы типов и переменных имеют одинаковые шапки.
Таблицы объектов и записей вобщем-то не таблицы а деревья.
Таким образом, всю декларативную часть целиком, скорее всего удобнее отобразить в виде дерева.