Драконограф писал(а):
А как представить вложением IF-ов - можно увидеть роспись?
Примерно вот так:
...
можно представить так:
...
Вот в том-то и дело, что примерно. Реально нужно прежде всего вспомнить об endif-ах - т.е. структурно разрешённых БП - соединителях плеч развилки (в графит-методе показаны
здесь - под меткой <Часть(i+1)>; для текстовой формы см. Свердлова - скажем, выдержку
в этом сообщении, более развёрнутая цитата
в этом соообщении). Тогда первый код запишется так:
Код:
progress
if Cond_1 then TrueAction_1
else FalseAction_1
END (*if Cond_1*)
if Cond_2 then TrueAction_2
else FalseAction_2
END (*if Cond_2*)
if Cond_3 then TrueAction_3
else FalseAction_3
END (*if Cond_3*)
failed FalseActon
END (*Progress*)
И выполняться будет, ессно, по цепочке - т.е. был у нас на предыдущем этапе труй или фальш, неважно - на текущем снова выполнится либо труёвый, либо фальшивый блок этапа (сообразно выбору плеча в развилке по условию)... а потом уж общефальшивый блок (и опять-таки независимо от прохождения на каких-либо этапах выше фальшивых маршрутов). Я так понимаю, желаемой логике PROGRESS-IF это не вполне соответствует
Или мы должны полагаться на то, что магические слова progress и failed меняют логику БП-соединителей (так, что для труёвого маршрута это местный END - причём на последнем этапе сразу переадресующий на END (*Progress*), а для фальшивого - всегда END от IF последнего этапа - указывающий на failed)... а это ревизия целевого прогязыка и должна транслироваться "не по Свердлову" (точнее, не по стандарту О-07)
Во втором случае полный код, как я понимаю, имеет вид:
Код:
bool ok := true
if Cond_1 then
TrueAction_1
if Cond_2 then
TrueAction_2
if Cond_3 then
TrueAction_3
else
FalseAction_3
ok := false
END (*if Cond_3*)
else
FalseAction_2
ok := false
END (*if Cond_2*)
else
FalseAction_1
ok := false
END (*if Cond_1*)
if not ok then
FalseActon
END (*if not ok*)
И выполняться будет по логике PROGRESS-IF только в случае, если endif-ы при вложении трактуются так, как показано опять же
здесь для БП <Часть(i+1)>. Т.е. из любой развилки выходим не в тело следующей (непосредственно объемлющей в "матрёшке") - а сразу в конец внешней - все endif-ы "запараллелены" по уровням вложения.
Так это или нет в Обероне-07 - не знаю, только странно получается - а если на каком-то уровне развилки цепочкой следуют - тогда как из матрёшки выходить? Спецификация Оберон-2 у Свердлова (выдержку см.
в этом сообщении) не оговаривает простое вложение IF-ELSE-END (в Паскале, помнится, было правило, надо смотреть) - возможно, потому, что предполагается использование IF{-ELSIF}-END. Но по логике он для прогресса не подходит (можно выбрать только один из труёвых блоков - либо единственный фальшивый).
Отсюда, видимо, и это замечание:
Уровень вложенности циклов почти равен количеству этапов.
Вот, наверное, почему Илье Ермакову
захотелось использовать новую специальную конструкцию. Хотя, может быть, Илья как-то обошел этот неприятный момент. Глядя на это и про goto невольно вспомнишь.
Только циклов тут нет - но вспомнили про них не зря... как и про БП (неструктурный, т.е. брейк/континуй, как минимум). Дело в том, что прогресс-конструкция в последней форме вложениями не получается (если менять логику endif-ов в развилках этапов, как говорил выше - то в терминах шампур-метода имеем лианную структуру). Если б не общий фальшблок - то можно было бы.
Мне, чтобы понять это, достаточно было построить графит-схему - и увидеть, что получаются лианные блоки. А пересадка лианы - это брейк и есть в текстовой записи (когда пересаживаем не по той оси порядка, от которой отрывали конец лианы, и не в пределах от её начальной вершины до конца оси). Допущение которого противоречит этому проектному решению по структурному редактору:
...я сделал следующие выводы применительно к PureBuilder:
В PureBuilder не применяются операторы перехода goto и операторы досрочного выхода exit, break, exit when, continue, return и аналогичные им.
...
Как Илья обошёл (бы) это - вариант показан
в этом сообщении - сам он не оценил соответствия, правда. Но логика конструкции там, как видим, другая, чем в прогрессе - и опять лианная.
В то же время структурный выход есть - как и ранее, привести к ЦД - вот его, видимо, и в этом случае можно построить без пересадок. Понадобится переменная номера ЦД-ветви - но она так и так нужна (если приводим не к ЦД - то флаги потребуются; кстати, создатель техноязыка и Илья указывают на то же применительно к силуэту - адреса силуэтных БП скрывают переменную состояния, являясь по сути её значениями).
Наверное, всё это можно было бы понять и не изучая граф-язык (как Сергей предлагает) - но тогда нужно привлекать эквивалентный текстовый метод структурного анализа - возможно, то что Илья предложил для определения шампур-схем как случая устремлённых графов.
Кое-что можно понять и по блок-схеме Сергея - но тут не соблюдается правило "вход и выход блока следования на одной вертикали" - поэтому порядок в осях надо мысленно восстанавливать. Идея вынести общий фальшблок на отдельную ось любопытна.