> -- PSV100 писал(а):
> По сравнению с исходным примером цикла в данном случае нет "ELSE EXIT" и наблюдается явное ключевое слово GUARD
Однако, оператор GUARD как защитное выражение верхнего уровня ограничивает "вычислительную мощность". В случае сложных условий, м.б. с несколькими уровнями вложенности, с применением операторов вида CASE...OF и др., потребуются вспомогательные средства, напр., дополнительные "управляющие" переменные как в примере с WHILE/done выше (от чего, собственно то, была попытка избавиться с помощью GUARD).

В целом, есть вариант борьбы со сложными условиями с помощью конъюнктов, но иным способом.

Относительно недавно на форуме Дракон-а была тема как раз по поводу -- демонстрация Дракон-схем как лучшего способа "выращивания деревьев решений":
Преимущества языка ДРАКОН для деревьев принятия решений

Рассмотрим "самым тяжёлый" случай -- с "неструктурным" переплетением "вопросов" (основная фишка Дракон-а):
https://forum.drakon.su/viewtopic.php?f=228&t=6666#p103696


По ссылке выше имеется полноразмерная картинка с кодом и краткой постановкой задачи -- обработчик события нажатия левой кнопки мыши для виджета TreeView. Итоговый генерируемый код переварить, в самом деле, сложнее, чем схему. Если оперировать текстовой формой алгоритма, то необходимо кардинально всё перекручивать, вероятно, с дополнительными "управляющими" переменными и пр. (или же goto). Однако и сама схема в данном случае из разряда: "нельзя понять одним махом, как можно понять анекдот" (там же рядом по ссылке). В данном варианте схемы не удалось избавиться от дублирования предикатов (в частности: machine.state === "expanding"). Попробовать найти альтернативный вариант схемы без возникающих пересечений линий и соответственно без разнесения функционала по веткам силуэта (иначе исходные явные отношения между условиями визуально разрываются) -- непростая задача, однако... Есть топологические ограничения и требования, но единственная методология построения схем -- метод "научного тыка".

Меня впечатлила методикаEsterel/Lustre. В одном из диалектов Lustre (ML-вариация для dataflow) введена дополнительная форма "сопоставления с образцом", точнее -- специальный оператор тестирования событий. Упрощённо суть в следующем:
## Код:
```
let node sum x y = z where
  present
  | x(v) & y(w) -> do emit z = v + w done
  | x(v1) -> do emit z = v1 done
  | y(v2) -> do emit z = v2 done
  | _ -> do done
  end
```

Выше "let node ..." -- объявление типа как аналога "активной ячейки" (active cell, а также и cellnet) из A2, с входными портами "x", "y" и выходным портом "z". Оператор present...end -- некий аналог CASE...OF или match...with в ML, но тестируется не указанный элемент-операнд, а любые доступные объекты. Так выражение "x(v)" -- извлечь значение из порта "x" в переменную "v", если порт содержит данные ("emit z" -- операция "эмиссии" сигнала, в данном случае для выходного порта, "do...done" -- аналог "begin...end" в ML). Семантика этого оператора основана на мотивах "join calculus" -- в отличие от прочих "защит" в виде логических выражений в данном случае образцы событий допускают только операцию конъюнкции. Тестирование вариантов событий упорядоченно (сверху вниз), методика предполагает указание сначала наиболее полных образцов событий, возможна ситуация "иначе" (компилятор способен проконтролировать охват всех вариантов событий если нет "иначе"). Все дублирования в тестировании/проверках компилятор должен ликвидировать -- это его забота построить эффективную лапшу из goto или чего там требуется на конкретной платформе.

Так достигается свёртка уровней и компактизация (теоретически и эффективность).