OberonCore

Нет никакой. LOOP - это не дейкстрин цикл.

Побочный эффект - изменение процедурой нелокальных переменных. Тут я сильно думаю. В контексте модулей - это могут быть поля в модуле - и только. Хотя у меня такое чувство, то побочный эффект вообще запретить полезо было бы. И посмотреть, что получится.

Это не побочный эффект, а нормальное условие...

Смущает слово "любой". А если веток несколько?

GUARD ничем не отличается от обычного expr/ Хотя для пущего подчеркивания смысла "охранны" может и пойдет.
А branch напоминает, и сильно, goto...


Ну да. Сложное условие разбивается на ряд более простых. Ошибок меньше совершается.


Ну так о том и речь. LOOP у нас только здесь, а WHILE у нас - везде!

Еще раз: в сложном расчете достаточно громоздкие части выражения в охране могут снова использоваться дальше. Редко, но бывает.

С.Г. прав, что раз они сложные, проблема оверхеда на вызов функции вроде как теряет остроту. Но зато появляется некая проблема разфокусирования взгляда программиста, когда чтобы разобраться с циклом, нужно лезть в какие-то отдельно стоящие процедурки-функции, да еще с побочными эффектами (хотя все эти побочные эффекты предполагаются локализованными в достаточно небольшом контексте).

То, что я предложил, выглядит достаточно гармонично -- нет ни разброса внимания, ни нарушений структурности.

Ведь выход один, и условия на выходе жестко определяются самими GUARD'ами, не считая побочных эффектов -- но тут это на том же уровне, на котором вообще побочность разрешена в Обероне.


--
В.Л.: да, из конца любой ветки возвращаемся в точку после LOOP. Ср. моделирование цикла Дейкстры в Компонентном Паскале (Приложение С в новых Алгоритмах и структурах данных):

LOOP IF ... THEN
...
ELSIF ... THEN
...
ELSE EXIT END END;

"никакой" -- это про что?

Это тут при чем?

Если условие нужно запихнуть в операнд, а процедура вычисляет что-то, и об успехе-неуспехе сообщает через OUT, то то, что она вычисляет, является с точки зрения вычисления логического условия побочным эффектом.

О чем "о том"?

Ага, прояснилось.
1. Я думал, что вы LOOP считаете каким-то вариантом дейкстриного цикла.
2. Начет побочного эффекта как результата выходного параметра. Да, это побочный эффект. Но при этом пройцедура должна все равно возвращать результат типа boolean, чтобы участвовать в логическом выражении. И тут еще интересный момент:

Вопрос о порядке вычисления выражений, сокращенных вычислениях и вообще, допускать ли такую фигню...
3. к тому, что лучше все же while в силу его повсеместной распространенности.

А я о чем, когда говорил, что приходится "оборачивать"?

А это к чему?

по-моему стоит сильно подумать, перед тем как выкидывать LOOP, который явно обозначает особый случай оптимизиации... Если разрешить GUARD в WHILE, то без вскрытия тела не увидеть - есть ли он внутри; это сродни обычному EXIT в WHILE.

См. также Убираю LOOP'ы

А я откуда знаю, о чем вы говорили? Я и говорю - прояснилось.
Но что вы опять имеете ввиду, говоря об "оборачивать"?
Выражение целиком оборачивать или переменную а оборачивать?

По идее сначала нужно более-менее внимательно прочесть (чего Вы не сделали), потом прояснить, что непонятно (чего Вы опять же не сделали, и я должен был гадать и пытаться наобум прояснять), потом всё остальное.

Ваш длинный ответ, написанный, как Вы только что признали, без понимания изначального сообщения, только всё запутывает.

В этом есть пунктик, но всё же не окончательный аргумент:

О "вскрытии тела" говорит нет особого смысла, т.к. GUARD допустим только на верхнем уровне тела. В этом смысле GUARD сильно отличается от EXIT.

В общем с самого начала понятно, что пихать что-то в WHILE не выглядит кошерно а приори, хотя добавка имеет жесткий смысл, и вполне в духе общей логики.
Ведь LOOP здесь получается сильно ограниченным, совсем близким к WHILE, так что вариант с выкидыванием LOOP и добавкой GUARD заслуживает внимания хотя бы как проверка решения на устойчивость.

Верно я понимаю, что описание алгоритма процесса Euclid (т.е. импер-знания о нём) на Вашем языке (буду, как обычно, называть по сокращению от ника автора - СП-язык) делится между вкладкой с приведённым импер-СП-текстом и вкладкой с импер-СП-текстом другой категории? Каково точное содержание каждой категории (т.е. что в импер-СП-описании одного процесса/программы помещается на вкладки каждого из разных типов) и критерии такого деления? Ну и если я понял неверно - то куда девается заголовок (какими средствами и где в СП-описании представляется часть смысла процесса, отражаемая заголовочными реквизитами)?

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

Небольшое резюме по операторам:
Условный (Дейкстра)
Этот же оператор является переключателем – семантика Дейкстры.
Оператор позволяет задавать одиночный if:

Обычный двухветочный if эквивалентен:

Вариант:

Семантика: если не выполняется ни одно из условий, то выполняется ветка else
Цикл (Дейкстра)

вариант:

Семантика: если нет ни одного истинного условия, то выполняется ветка else и цикл завершается

цикл while:

цикл do while (repeat):

вариант: true можно пропускать вместе со скобками

Это чем-то отличается от
?

Похоже, что нет. При означенной семантике.

На самом деле заголовок функции не нужен, потому что алгоритм функции записывается не внутри длинного программного кода, а в отдельной вкладке интерфейса. Соответственно, название функции отображено на рисунке на веб-странице в строке Project_1 > Module_5 > Euclid. А что касается возвращаемого значения, то оно должно объявляться и специфицироваться ниже записи алгоритма функции - в отдельной таблице в панели элементов структуры.

Соответственно, на вкладке Project_1 > Module_5 функция Euclid будет отображаться отдельным элементом со своим именем. Можно будет прямо во вкладке этого модуля создать "пустую" функцию-заглушку с каким-нибудь именем, а подробной разработкой этой функции заняться как-нибудь потом, когда будет время. Щелкаем по элементу, отображающему новую функцию - и оказываемся в пустой вкладке этой функции, которую (вкладку) предстоит заполнить содержанием.



Конечно, теоретически можно заменить ключевое слово while каким-нибудь значком или иероглифом. Но, во-первых, при этом потеряется возможность проговаривать и обсуждать код программы. Во-вторых, ключевое слово while и так воспринимается именно как значок, а не как исходное слово английского языка. Оно даже удобнее русского перевода, так как воспринимается как специфическая часть программы с особым значением, а не как слово с традиционными значениями (это аргумент против русского синтаксиса).

А как Вам такой вариант? Разумеется, лишние ветви могут быть удалены.

Пример цикла Дейкстры (алгоритм Эвклида) в PureBuilder - теперь в виде картинки:

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

Человек же признавался не раз, что не программист.

Выглядит симпатично.

Почему кто-то тут может сломать себе шею -- совершенно непонятно.
Пример таких языков, как Оккам, Питон, Хаскелл, F# показывают, что всё тут будет нормально, а для новичков в программировании -- просто отлично...

Я буду не одинок. Такой вариант алгоритма Эвклида мне попадался много раз на разных языках программирования. Он уже стал почти столь же популярен для демонстрации цикла Дейкстры, как пресловутый "Hello, world". Единственное, что я сделал, это очистил его от лишней синтаксической шелухи, которая только увеличивала шансы сломать шею.

Если Вы имеете в виду, что в паре строчек кода содержится слишком много скрытого математического смысла, то я соглашусь. Писать так обычные программы, конечно, не стоит. А вот для библиотечных функций, которые можно отлаживать хоть неделю на каждую строчку кода, такие алгоритмы вполне нормальны. Для этого существуют яйцеголовые математики. Я же привел всего лишь демонстрационный пример, который многие используют для демонстрации цикла Дейкстры.