Цитата:
Зачем нужна альтернативная форма цикла Дейкстры, понять я так и не смог.
Нет никакой. LOOP - это не дейкстрин цикл.
Код:
Оптимизации в том смысле, что операнды конъюнкции в охранах могут быть сложными и вычисляться с побочными эффектами.
Побочный эффект - изменение процедурой нелокальных переменных. Тут я сильно думаю. В контексте модулей - это могут быть поля в модуле - и только. Хотя у меня такое чувство, то побочный эффект вообще запретить полезо было бы. И посмотреть, что получится.
Код:
Например, некое условие может получаться как OUT-результат процедуры.
Это не побочный эффект, а нормальное условие...
Код:
Во-первых, допускаются несколько веток. Для конкретности пусть будет ключевое слово BRANCH:
[code]
LOOP
последовательность операторов
BRANCH
последовательность операторов
......
END
[/code]
Начинаем выполнение в точке сразу после LOOP, куда возвращаемся после выполнения последовательности в любой ветке.
Смущает слово "любой". А если веток несколько?
Цитата:
Дальше: EXIT запретить, но вместо него требовать, чтобы в каждой ветке -- и обязательно только на самом верхнем уровне -- присутствовал хотя бы один оператор "охраны", аналогичный ASSERT, например, в таком виде:
GUARD( логич. условие );
Смысл оператора: при выполнении условия выполнение ветки продолжается;
в противном случае попадаем в точку сразу после следующего BRANCH, а если такого нет, то последнего END.
GUARD ничем не отличается от обычного expr/ Хотя для пущего подчеркивания смысла "охранны" может и пойдет.
А branch напоминает, и сильно, goto...
Цитата:
Например, лин. поиск
Код:
WHILE (ограничение поиска) & ~(условие поиска) DO
перейти к след. кандидату
END;
переписывается так:
[code]
LOOP
GUARD( ограничение поиска );
GUARD( ~(условие поиска) );
перейти к след. кандидату
END
Ну да. Сложное условие разбивается на ряд более простых. Ошибок меньше совершается.
Цитата:
Можно и вообще выкинуть LOOP, разрешив такой GUARD в обычном WHILE ... DO ... ELSIF ... DO ... END
Ну так о том и речь. LOOP у нас только здесь, а WHILE у нас - везде!