DRAKON.SU

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

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

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

Уважаемый Эдуард!

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

Перефразирую: дополнительный вход в веточный цикл запрещён.

Из этого правила НЕТ исключений.

Таким образом, наиболее общей является формулировка:

А что есть веточный цикл?
Разве он ограничивается какими-либо конкретными конструкциями языка?
Если нет, то, следовательно, существует только в воображении разработчика, но не как строгая алгоритмическая конструкция.

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

Не понял в чём сложность ...
Порядок следования веток известен, начальные конечные ветки цикла известны ...
Проблемы с редактором не вижу.

А что, разве начальная и конечная ветка помечаются специальной иконой?
Если это так, значит, я был невнимателен, и всё не так страшно.

Таки да : )
С чёрным треугольничком ...

Если запретить вход в веточный цикл, то Дракон сразу перестаёт поддерживать автоматное программирование.

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

Согласно авторскому определению в книге «Как улучшить работу ума»

Границы визуально задаются иконами с чёрными треугольниками.
Разрешён только один вход в веточный цикл и, по всей видимости, множество выходов. Что, кстати, присутствует и в обычном цикле (который не ДЛЯ).

Ну, вот такой он, веточный цикл : )

По пункту а) — какая неоднозначность имеется ввиду? (в этом месте однозначно выходим из цикла(ов), при достижении некоторого состояния)

По пункту б) — не понял, возможно имелся ввиду выбор иконы «Имя ветки»? (выход из веточного цикла в предыдущие ветки невозможен по определению, так как при этом образуется повторный вход)

Вопрос Владимиру Паронджанову

В книге «Как улучшить работу ума» сказано


Значит ли это, что конструкция, показанная на рисунке ниже, некорректна (учитывая, что силуэт может не содержать икону «Конец»)?

Если Дракон, в его нынешнем состоянии, использовать для автоматного программирования, то пропадает возможность использовать ветки для организации ветвления внутри перехода от состояния к состоянию. Иногда это полезно. Для обеспечения такой возможности я отделяю ветки, обозначающие состояние, от других веток словом СОСТОЯНИЕ и допускаю : ) переход от состояния к состоянию через икону Выбор перед входом в силуэт. Об этом писал здесь.

Зато никак визуально не задаются условия продолжения и окончания цикла.

Вот "канонический" вид двух вложенных циклов:

Выполним эквивалентное преобразование... не алгоритма даже, а его представления на языке Дракон:

Продолжим эквивалентное преобразование:

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

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

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

И это только ещё самый элементарный пример!

Не совсем понял, почему "пропадает"... Согласен с тем, что "полезно" и "отделяю"

(мысль навскидку) Поискать аналогии и распространить ограничения "одномерного" структурного программирования на второе измерение?

Сама идея силуэта, насколько я понимаю, как раз прямо этому противоречит.

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

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

Если "отделить" ветки с состоянием от веток с переходом, то ничего не "пропадает" : )

Во вселенной Дракона такая схема не может существовать по определению, так как у неё имеется второй вход в цикл : )



Куда угодно назначать нельзя. Появляются доп входы.

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

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

Т. е. бывают однозначно невозможные выходы влево (когда образуется доп вход в цикл) и выходы влево без образования доп входа (что с ними делать?).

А мне кажется, что в данном случае Вы злостно путаете алгоритм и его представление (отображение, view).
Алгоритм со волженными циклами вполне структурен, легален и валиден
А то, что некоторые гомеоморфные преобразования отображения алгоритма недопустимы - это проблема отображения, не так ли?

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

В алгоритме - не появляются. Появляются лишь в отображении (представлении). Что опять же есть проблема представления, а не алгоритма.

Алгоритм - здесь основное. Основная сущность. Она строга и непротиворечива.
В отображении всегда могут появляться противоречия. Потому что невозможно отобразить объёмную структуру на плоскость (а плоскую - в линию) без разрывов и пересечений.

Отображение же всегда играет подчинённую роль и служит вспомогательным инструментом.
Поэтому нельзя заморачиваться на проблемах отображения!

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


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


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


Что-то я в растерянности ... : )
А что мы здесь тогда обсуждаем?

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

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

В данном случае инструмент оказался неудобен (и даже, вероятно, неадекватен).
Следовательно, есть два пути: искать более адекватный инструмент или улучшить то, что есть.

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

Пока рановато! Не созрели...