Владимир Даниелович,
речь не о фатальных ошибках Дракона, а о границах эффективного (и именно эффективного) его применения в контексте понимания самодостаточности алгоритма. Любой алгоритм задаётся исходя из характеристик исполнителя или, в целом, исполнительской среды (если такова выделяется при моделировании). В результате для алгоритмов формируются требования и правила:
- полноты или частичности определения алгоритма, предполагается или нет некая "интеллектуальность" исполнительной системы;
- возможности задания квазиалгоритма (квазиалгоритм, в отличие от частично определенного, предполагает неполноту формализации, например, художник вряд ли сможет составить подробнейшую схему алгоритма написания конкретной картины, требуются условные абстракции);
- каковы принципы обработки возникающих ошибок и иных нарушений исполняемых инструкций (в т.ч. допускается ли возможность игнорирования этого аспекта в алгоритме, предполагая или нет, что исполнительная система весь удар берёт на себя, например, для случая компьютерного исполнителя, система при возникновении нарушений как-то фиксирует этот факт (или нет) и прерывает процесс, при необходимости переинициализирует или перезапустит исполнение и т.п. Соответственно, в подобном случае, проектируемый алгоритм должен рассматриваться в сопряжении с другими алгоритмами ядра исполнительской системы).
И чем подробнее алгоритм, тем сложнее его определить, и ..., в общем, в
"нормализованном описании алгоритма" Эдуард верно подметил:
Ильченко Эдуард писал(а):
...Попытки учесть граничные условия, реакцию на аварии, явно описать в схеме сообщения диспетчеру, приводят к дикому : ) разрастанию схемы, либо к не менее дикой : ) дефрагментации её же. При этом и технолог и программист с трудом понимают что же там должно происходить...
Методы борьбы со сложностью и с возникающими пересечениями -- абстракция и декомпозиция, вызывающие разделение функционала по связанным схемам или веткам внутри схемы. Однако, в ряде случаев разнесение тесно связанных по контексту элементов нежелательно или неэргономично, но в Драконе не развит другой метод -- композиция (прежде всего, некая функциональная композиция -- вложенные блоки, "замыкания", "лямбды", встроенные функции, комбинаторы функций и т.п. механизмы). Наиболее естественные решения для композиции предлагал Степан Митькин:
ДРАКОН и лямбда-выражения. Если за основу для выделения блоков взять иконы "FOR-END", то возникает потребность согласования представления разных типов блоков, включая и сами циклы, плюс учесть возможные боковые выходы из блока, которые предлагал Дмитрий Дагаев:
здесь плюс след. сообщение.
Возможная сфера применения блоков разнообразна: помощь для создания универсальных обобщённых алгоритмов, использование блока в качестве аргумента для икон (внутри блока возможны "захваты" или ссылки на элементы, определенные перед блоком), выделение структурных областей (например, в начале которых создаются элементы, в конце -- удаляются), указание состава контекстных действий (например, после операции инициализации ресурса задаётся блок действий по его освобождению, наглядно отражающий взаимосвязанный контекст всех операций), но сам выделенный блок будет исполняться в ином месте алгоритма (например, в самом конце освобождается ресурс вне зависимости от возможной аварийности работы), и др.
В отношение блоков необходимо дать два важных замечания:
- предполагается, что в рамках конкретной исполнительской системы определена формализация функциональной композиции, имеется грамотная методика и дисциплина её применения (например, у медицинского алгоритмиста может возникнуть недопонимание (как минимум, поначалу), зачем вообще нужны какие-то блоки, если и так пока достаточно минимума простых средств без никаких усложнений. С другой стороны, тем, кто составляет схемы в применение к функциональным ЯП, оперировать без блоков затруднительно);
- функциональные блоки должны быть максимально компактны и монолитны, иначе вряд ли можно говорить о какой-то эргономике и оправдывать их применение.
Однако, и в относительно маленьком блоке могут быть развилки ("if" и "case"), циклы, и, в общем случае, могут возникать пересечения. Для борьбы с пересечениями используется силуэт. Если придерживаться требования монолитности, то силуэт должен быть встроенным внутри блока, т.е., фактически, схема внутри схемы. В этом случае вряд ли решение будет компактным и эргономичным. Если использовать общий единый силуэт схемы, т.е. монолитный блок должен быть разбит на части и разнесён по веткам -- значит применять декомпозицию, которую и пытались избежать путём применения композиции. К тому же нет однозначного мнения как эргономично выделять "многоветочные" блоки, согласно
этой темы.
Таким образом, вложенные блоки для задач функциональной композиции могут применяться весьма ограниченно. И проблемы, рассматриваемые в
"Преобразование графов", конечно же, решаемы, но путём абстракции и декомпозиции, в силу нерешенности вопроса насчёт композиции. И в некоторых случаях контекстно тесно связанные элементы вынужденно разлетаются по веткам (или схемам), также ещё может возникать эффект "разряженности" схемы, когда некоторые ветки имеют очень мало содержательных элементов, формируя пустоты на схеме и длинные свисающие линии.
Для многих это пустой разговор не о чём, но не всегда всех удовлетворяют такие решения. Это и есть некоторые артефакты когнитивных правил Дракона. Это не фатальные ошибки, это целевые особенности языка.
Традиционно подобные вопросы остаются без конструктива, поэтому приводить примеры конкретных схем не буду, т.к. пока не готов одновременно предоставить и конкретные предложения по усовершенствованию.