DRAKON.SU

Здравствуйте. Только недавно открыл для себя Дракон. Прочитал книгу Паронджанова "Как улучшить работу ума". Скачал Дракон-редактор и уже нарисовал для себя несколько полезных Дракон-схем. Спасибо большое Владимиру Даниэлевичу и Геннадию Тышову за самоотверженную и очень нужную работу!

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

Дракон-редактор позволяет рисовать вот такую, явно неструктурную, конструкцию (см. ниже):

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

Вопросы к Владимиру Даниэлевичу:
1. Цикл ДЛЯ чем-то структурно отличается от других циклов, для которых такая конструкция невозможна, так как будет пересекать обратную петлю?
2. Если ответ на первый вопрос отрицательный, то можно ли изменить начертание икон цикла ДЛЯ в соответствии со вторым рисунком?

Да, здесь все правильно.

Если хотите, перечитайте главу 16 "Как улучшить..". Дейкстра разработал
методы структуризации для ТЕКСТОВОГО программирования.

Переход от ТЕКСТОВОГО к ВИЗУАЛЬНОМУ структурному
программированию позволяет выявить новые возможности,
которых у Дейкстры не было.

Но это не плохо, а наоборот, хорошо.





Для всех циклов (и вообще для дракон-схем) действует правило
"Пересечения запрещены".



Нет, нельзя. Икона "конец цикла ДЛЯ" не должна иметьвыход вправо.

Уважаемый Alex_Bob!

Мой ответ имеет чисто формальный характер.
Суть Вашего вопроса я, к сожалению, не понял.

По-видимому, правила дракона НЕ позволяют Вам
решить какую-то важную для Вас задачу.

Поясните суть Вашей задачи. И мы совместными
усилиями постараемся найти для Вас ответ.

Справедливость утверждения сомнительна.

Может быть, в историческом аспекте, да.
Но в логическом, для теории в окончательном виде, скорее, нет.
Теория Дейкстры "танцует" от логики, а не от текста.

Владимир Даниэлевич, спасибо за быстрый ответ.

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

При построении Дракон-схем с вложенными циклами ДЛЯ, обратил внимание на их ненаглядность и начал пытаться экспериментировать. Слабо спасают положение боковые комментарии. В Дракон редакторе Тышова можно сдвигать икону в сторону относительно оси шампура. Получается как-то так



Уже лучше, но если вложений больше, уезжаем далеко от шампура.

Переформулирую вопрос так: Для чего была введена отдельная нотация для изображения цикла ДЛЯ? в чем эргономическое преимущество изображения цикла ДЛЯ в принятой Вами нотации по сравнению с изображением цикла в виде обратной петли? В каких случаях оно проявляется? Когда следует применять данную нотацию?

В нарисованном мной десятке схем с циклами такая нотация во всех случаях проигрывала в наглядности циклам с обратной петлей.

Кстати Дракон-редактор Тышова позволяет и следующие, запрещенные спецификацией конструкции:

Первая образует еще один цикл, а вторая образует второй вход в цикл. Но это уже вопрос к автору редактора.

1. Цикл ДЛЯ заимствован из Гост 19.701--90 (Это действую-
щий на сегодня Гост на блок-схемы).
2. См. этот Гост пункт



Я использую этот цикл, только как цикл с параметром.
См. стр. 178 рис. 90 пункт 6,
стр. 182 рис. 93,
стр. рис. 186, рис. 187.


Ответ на этот вопрос ясен из сопоставления рис. 49 и рис. 50
на стр. 136. По моему, справа лучше, проще и нагляднее.
Как Ваше мнение?

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

Уважаемый Федор Васильевич!

1. Полностью согласен, что


2. Вполне возможно, что в даном конретном случае мое утверждение
хромает. То есть Вы ПРАВЫ, а я НЕ ПРАВ.

3. Если же брать ситуацию в целом, то, по-моему, у меня нет ошибок.

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

5. Визуальное структурное программирование (со ссылками
на Э. Дейкстру) изложено в "Главе 16. Визуальное структур-
ное программирование" на стр. 245--266 в книге "Паронд-
жанов В.Д. Как улучшить работу ума: Программирование
без программистов -- это очень просто! М.: Дело, 2001."
viewtopic.php?p=21078#p21078

6. Напомню начало Главы 16. Визуальное структурное
программирование



7. Если Вы обнаружите у меня ошибку, буду очень
благодарен.

Цикл ДЛЯ - такой частный и маловажный случай... Что его и мусолить не стоит. И уж если он есть, то никаких фантазий на тему досрочных выходов (даже если на плоскости это наглядно и проверяемо), я считаю, не нужно.

Поддерживаю. Более того, считаю что цикл ДЛЯ следует вынести в "макросы" визуального программирования.

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

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

ИМХО

Локальные переменные не с потолка берутся. Любой счётчик требует места в памяти для хранения, и я считаю, что не стоит этого прятать от пользователей. Даже простейший LOOP в ассемблере требует места хранения (ECX) для счётчика. А кроме того, не следует забывать об операции сравнения с границей цикла, о которой тоже никогда не задумываются.
Поэтому я и предлагаю ввести понятие "визуального макроса"/"мета-схемы". Делаем метасхему для цикла ДЛЯ на базе цикла ПОКА и радуемся тому, что реализация скрыта внутри квадратика.

Аналогично. Но на одних нас жизнь не заканчивается.

Попробую по-подробнее
Предположим, что некий Автор делает конкретную реализацию ДРАКОН-а над неким языком. Может даже и интерпретируемым... И там есть такая синтаксическая премудрость, как "цикл со счетчиком", и работает эта встроенная премудрость, во много раз быстрее, чем эмуляция того же самого "на рассыпухе".
Как Вы предлагаете строить кодогенерацию этому Автору, после того, как мы выкинем FOR из числа примитивов
Это будет несколько похоже на декомпозицию асм-кода в шаблоны ЯВУ, как мне кажется. И именно такое я и обозначил выше, как "почесывание левой ногой правого уха"

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

Дело в том, что нужно искать общий базис, а не сложные системы преобразований
текст<-->схема.

Не согласен. Утверждается, что язык Дракон имеет строгую математическую основу. Об этом говорится в Главе 17 книги Паронджанова "Как улучшить работу ума". Но внимательно читая эту главу, нельзя не заметить, что данное математическое обоснование подходит к ЦЕЛОМУ КЛАССУ ВИЗУАЛЬНЫХ ЯЗЫКОВ, ПОДОБНЫХ ДРАКОНУ, но имеющих различный графический синтаксис и множества синтаксических правил. Например, если заменить изображение цикла ДЛЯ тем, которое я предлагал в первом посте, не меняя больше никаких правил, то построение схем из первого и второго поста становится невозможным, так как будет пересекаться петля цикла.
Или, наоборот, если снять в спецификации Дракона ограничения при пересадке лианы, то все 3 варианта схем становятся возможными.
Так что, реализуя Дракон-редактор, влегкую можно сделать инструмент, который будет рисовать схемы из тех же элементов, какие существуют в описании Дракона, но они не
будут являться Дракон-схемами (пример - набор графических примитивов для MS Visio).

Понять, почему автор пришел именно к такому набору спецификаций, чрезвычайно важно. Возможно, время выявило слабость или избыточность/недостаточность каких-то из них. В частности, большое количество икон для работы с реальным временем явно связаны со спецификой применения бортовых систем, а для целей обучения в школе не очень нужны.
Мне на данный момент не совсем ясно, "Дракон" - это обозначение для семейства языков или один язык с конкретной спецификацией, описанной в книге?
Является ли эта спецификация потенциально расширяемой для частных применений? Тут есть отдельная тема про изображение исключений на Дракон-схемах. Предлагались различные варианты отображения с помощью имеющегося синтаксиса. Ни один из них нельзя признать полностью адекватным. Возможно ли решение с помощью ввода дополнительной иконы и ввода дополнительных правил? Можно привести другие примеры.
Например, как наглядно отобразить на Дракон-схеме алгоритм рекурсии?

Что касается цикла ДЛЯ, попробую ответить себе сам. Как мне кажется, его применение оправдано там, где основу алгоритма составляют действия внутри цикла и их нежелательно уводить с шампура.

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


2Alex_Bob - согласен

Вы не поняли мою мысль.
1. Редактор содержит только стандарнтые примитивы.
2. Примитивы можно объединять в группы (мета-схемы).
3. Для каждой мета-схемы можно задать особые принципы генерации кода.
4. Редактор может предлагать пользователю заменять "узнанные" участки алгоритма на мнемосхемы.

Поскольку у меня сейчас нет под рукой на чём можно нарисовать схему попробую пояснить на тексте:
1. Пусть у нас есть программа:

2. Редактор знает, что:

и

могут быть заменены на


Поэтому совершенно не важно как была получена схема и какова её предыстория.
Главное ЧТО нарисовано на схеме.

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

А про "узнанные" - далеко не все так просто. Точнее - все далеко не просто.
Начать можно с того, что для "узнавания" следует поинтересоваться, изменял ли кто параметр цикла в процессе исполнения some_do.....
И - никогда не кончить, между прочим.
Доказательство... ну пусть будет от противного:
Посмотрите в коды почти любого EXE-шника, изготовленного на ЯВУ. Насколько успешно они там "узнают" специфичные для проца команды. Порой просто волосы дыбом встают.
Особенно, если работают с битами, там вообще - туши свет.
Так вот - они еще, хоть и начали, но еще не кончили (а может и никогда не кончат) процесс "узнавания".
Если бы с "узнаванием" все было так просто, как Вы говорите, мы бы увидели совсем другую картину, а Мастера Дзена давно бы вымерли как класс

Чего-то мне именно так пока кажется.

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

Чем плохо?
Возможно так лучше?

Да нормально всё...

Нормальная структура.

Вообще, Драконовские IF-ы можно считать полностью "безопасными".

С циклами - вопрос шире. Фактически, классно с несколькими исходов из условия цикла (когда конъюнкт разбит на две развилки - и по нарушению каждого отдельный исход. Как в линейном поиске - "нашли- не нашли"). Можно представить себе ситуацию, когда перед каждым конъюнктом нужно провести действие по его вычислению. Но как-то бы предупредить попытки клепания выходов из тела цикла (т.е. той части, которая продвигает состояние и восстанавливает инвариант цикла).
Если же событийная логика - то тут уж в любом случае надо ветки использовать, а не обычный цикл.

Возможно, так лучше - повторы исключены.