DRAKON.SU

Драфт здесь -> Конечно, могут быть ошибки, но уже собирается само. Писишная часть на подходе.

hist
2009-04-28: добавлены Дракон-схемы в pdf-формате
2009-04-27: исправлены мелкие недочёты

некоторые итоги:

"++"
1. набор соглашений по использованию икон (см. любой лист проекта ГНОМ-схема слева). Эти соглашения устанавливают соответствие между макроиконами Дракона и управляющими конструкциями целевого языка программирования. Очевидное решение может быть в виде набора словарей под различные целевые языки программирования. TAU на сахара.ru привёл в качестве примера систему ГРАФКОНТ с шаблонами программных текстов для каждого вида икон. В дальнейшем эти словари (или шаблоны) должны использоваться для автоматической трансляции Дракон-схем.
В пределах листа вроде бы нерационально использовать несколько целевых языков, но, как назло, некоторые программы запросто обращаются, допустим, к SQL-серверу или скриптовому движку. Если с визуализацией запроса в Драконе пока никак, то многие скриптовые языки естественным образом могут быть отображены на Драконе. Поэтому я не стал бы навсегда отвергать возможность использования нескольких словарей на одном листе. Чтобы иметь возможность рисовать тот самый Data Execution, который в отдельных местах надо душить нещадно, а в других - без него никак.

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

"--"
3. источник дополнительных ошибок - ручная расстановка управляющих конструкций в программных примечаниях. Это весьма затрудняет начало работы с первым проектом для данного целевого языка и без выработки системы соглашений (см.п.1) приводит к запутыванию проекта.
4. первый лист проекта (c которого запускается сборка) получился абсолютно неинформативным(технологическим). Это неправильно. По моему, первый лист должен давать представление о системе в целом.

Решил показать вариант вашего документа с применением 1-й иконы "Проект" (ранее называлась "Лист"), в которой имеется несколько ссылок на иконы "Сборка текста" других документов, взамен нескольких икон с 1 ссылкой в каждой.


Может, на него следует поместить икону "Комментарий" схемы "Гном" с описанием назначения устройства.

Может, кто-нибудь потратит время и сделает pdf с примерами схем из проекта Рэйлвэй Кагена?

Просто я думаю, что многим было бы так удобнее посмотреть.

2 Геннадий Тышов:
Вариант с одной иконой "Проект" намного лучше. Спасибо.
Насчёт текстового описания на первом листе - по-моему не очень хорошая идея. Тут лучше 100 раз подумать.

2 Илья Ермаков:
Доки в pdf'е добавлены в первое сообщение темы.
Более маниакального занятия, чем запихивание png в pdf с подгонкой форматов у меня ещё не было Видимо стоит рассмотреть варианты с djvu и автодокументированием.

как собрать исходник и где искать структурность?

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

2.структурность структурности - рознь.
Подробнее:

а. классики(разные) о структурном программировании [..пропущено..]
б. ещё год назад Илья Ермаков (здесь) достаточно ясно высказался насчёт размерности структурных предложений - "двумерное структурное программирование даёт преимущества, не лишает нас формальности и при этом просто не укладывается в линейную текстовую модель". Цена соблюдения структурности линейного типа в результате трансляции из системы двумерного структурного программирования - как минимум, дублирование исходного кода. А надо ли её платить, учитывая п.1?
Вложение:
Комментарий к файлу: Устранение пересечений для линейной модели. Метод - дублирование кода.
1.7z [825 байт]
Скачиваний: 711



в. как это ни странно, Дракон дает шанс языкам с GOTO.
GOTO может сыграть положительную роль только при использовании его на автоматическом уровне(аналогично невидимому inc(PC)), когда нет прямой возможности "пошалить ручками". Автоматическая трансляция Дракон-схемы в язык с GOTO оказывается в выигрышном положении относительно ЯВУ, не имеющих такой конструкции

Полностью согласен. Эта мысль меня давно и очень сильно волнует. Поскольку конструкции Дракона "не ложатся, точнее, не всегда ложатся" в конструкции текстовых языков, возникает вопрос, как быть?
Есть два ответа.
Ответ 1. Надо использовать только те конструкции дракона, которые успешно ложатся в имеющиеся текстовые кострукции. Недостаток этого варианта в том, что часть преимуществ Дракона пропадает. Это плохо, так как жалко добро терять.

Ответ 2. При трансляции с выхода дракон-редактора в исходные коды целевого языка ПОВСЕМЕСТНО (ИЛИ ПОЧТИ ПОВСЕМЕСТНО) ИСПОЛЬЗОВАТЬ GOTO. В этом случае будут сохранены ВСЕ преимущества дракона. Но! это возможно (без выкрутас) лишь в том случае, ЕСЛИ ЦЕЛЕВОЙ ЯЗЫК ИМЕЕТ GOTO.
Страшно ли это? По-моему нет. Так как в гибридном языке Дракон-целевой язык, последний отчасти играет роль ассемблера, в который GOTO вставляется автоматически (что безопасно), а не ручками.

Уважаемый Рэйлвэй Каген!

Большое спасибо, что Вы высказали эту мысль в явном виде.
Но как же быть в итоге? Ведь в Обероне (если я не ошибаюсь) нет GOTO. Выходит, что союз дракон-Оберон не может быть ИДЕАЛЬНЫМ? Или я что-то напутал?

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

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

Смиялсо.
Ну вот и пришли к закономерному итогу всей этой возни: оператору GOTO.

Знаете, просто сказать, что «все плохо», это еще ничего не сказать. Появление GOTO не есть признак непрофессионализма, это признак знакомства с работами Дейкстры

Возможно, что я сейчас выскажу мысль, которую уже здесь высказывали, но уж очень она к месту, как мне кажется.

За всеми этими разговорами о GOTO как-то упускается тот факт, что вовсе не обязательно производить однозначное соответствие «икона — кусок кода». Можно же сделать соответствие «схема — конечный автомат».
А вот последний смело может быть реализован без использования GOTO.

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

Далее, если порассуждать над этой схемой, можно прийти к тому, что Borland в свое время назвала two-way tools. Как в Дельфи можно назначить обработчики событий и из инспектора попадать в код в нужную процедуру, так и из Дракон-редактора в перспективе можно попадать сразу в точку реализации иконы в автомате (естественно, с соответствующим синтаксическим [косметическим] выделением точки реализации в коде).

Кстати говоря, подобный подход очень сильно перекликается с «гнездами» Горбунова-Посадова в его «Расширяемых программах». Сам конечный автомат в основном неизменен в рамках одного языка. Изменяется лишь небольшой его блок (case-часть). В рамках же case-элемента меняется только внутренняя часть, сам же элемент («гнездо») неизменен. И в рамках этой модели можно получить большой выигрыш от взаимодействия «графической» части и «содержимого гнезда».

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

Материалы по теме:
Психология автоматного программирования
Расширяемые программы

Так это всё понятно. Есть 4 решения, все они здесь перечислялись:
1. Использование теоремы Ашкрофта-Манна, или автоматов, я не вижу здесь разницы (switch внутри цикла).
2. Иногда можно использовать подходящие конструкции типа loop со многими exit, если они есть в языке.
3. Дублирование кода.
4. Оператор GOTO.
Но я лично критикую Дракон совсем не за это. Можно писать абсолютно структуированные блок-схемы, или Дракон-схемы, это ничего не меняет. Просто блок-схемы - это тупик.

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

Владимир Даниелович, по поводу использования GOTO - это не моя мысль. Это факт, отмеченный во многих работах, так или иначе использующих диаграммную технику. Этот факт имеет простое и наглядное обоснование. Пусть на сторонах проволочной модели прямоугольника заданы направления обхода, соответствующие движению по диагонали от верхнего левого угла к нижнему правому(развилка в верхнем левом углу). Возьмём модель за эти углы по диагонали и попробуем растянуть её в линию с сохранением направления обхода. Не получается? Чтобы сделать это, потребуется сделать 2 разреза и поставить две метки и два GOTO.
Отсутствием GOTO в Обероне начинается и завершается список недостатков этого союза. А вот для Дракона и Си список достоинств их союза состоит лишь из наличия GOTO.

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

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

Идея, собственно, состоит в том, чтобы создать такую IDE, в которой структура модуля разрабатывается на Драконе. Далее, двойной клик по иконке раскрывает окно с текстом процедуры, написанной в обычном традиционном стиле, например, на Обероне. То есть Дракон-схема выполнят в том числе роль своеобразного инспектора объектов.
Идейка, конечно, пока сыровата. Как всегда обычно бывает, есть много нюансов. Вместе с тем открываются и новые не виданные доселе возможности. Например, условный вызов процедур. Хотя полезность от таких возможностей пока не очевидна и, наверное, спорна.

Ещё хочу высказать своё предположение о том, что язык Дракон предлагает свой способ борьбы со стилем "спагетти", отличный от классических принципов структурного программирования. Здесь тоже спасение в структурах, но иная реализация. Может именно этим объясняется то, что некоторые драконовские схемы, которые трудно обвинить в неструктурности, "не ложатся" на тот же Оберон или КП.

Madzi: "схема с GOTO может быть преобразована к схеме без GOTO.."

-- Это так, но в двумерной Дракон-схеме GOTO нет и не предвидится.

Евгений Темиргалеев: "..если работать по более мягкому принципу правки при разработке.."

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

Peter Almazov: "Смиялсо."

-- Вы екзешник почитайте. Там столько GOTO, что Вас просто порвет от смеха. Да, и P.S. из второго своего сообщения подотрите. Пожалуйста. Он неуместен в данной теме.
За предупреждение о тупике - спасибо. У меня есть КАСКО.

Димыч: "вовсе не обязательно производить однозначное соответствие «икона — кусок кода». Можно же сделать соответствие «схема — конечный автомат»."

-- Можно. В этом случае цена вопроса - введение переменных для состояния автомата. Но проблема даже не в этом. В общем случае задача преобразования потребует аналитического решения, а это значительно сложнее в реализации, чем дублирование кода или применение GOTO. Очевидно, что решения, корректно использующие автоматный подход на архитектурном уровне, безо всяких проблем транслируются в линейный структурный(!) текст (А.А.Шалыто(СПбГУ ИФМО)).

PS убрал.
А зачем мне читать екзешник? Я с ним не имею дела ни на каком этапе. В отличии от.
Вы еще посоветуйте почитать то, что наделает компилятор для RISC-машины.

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

Это первый шаг к пониманию, что наличие кода jmp в .exe(да и в .obj тогда уже) и GOTO в промежуточном результате сборки - это эквивалентные "изъяны природы".
Нежелательно GOTO при работе человека с линейной текстовой моделью - так не используйте. Но здесь то работа с плоским представлением и в нём нет GOTO, а есть свои методы структуризации.

Например в BlueJ для Java структура классов пакета представляется визуально.

Я склонен полностью принять точку зрения Рэйлвэя Кагена.

Вопрос к Евгению Темиргалееву

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

Суть моего вопроса: ЕСЛИ МЫ РАБОТАЕМ, НАПРИМЕР НА ДРОНе,
ТО ЗАЧЕМ НАМ ЛЕЗТЬ С ПРАВКАМИ В ACTIVE OBERON?
Может быть, в этом случае можно рассматривать ACTIVE OBERON как аналог ассемблерного текста, екзешника? Или я не прав?