OberonCore

Да, именно так - но более общо мы говорим не о массивах/списках, а о последовательностях ситуаций.
Здесь как раз и есть двумерность в ситуациях, так сказать.

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

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

Вот в разбираемом примере первым желанием было взять действие (выборка пары команд и их выполнение), а потом уже начать повторять. Потом выяснилось, что цикл недостаточно "часто обращается", неудобно.
Если бы мы задумались исключительно об условиях и об их проверках, то цикл у нас сразу получился бы с числом обращений как раз по числу проверок (в 4 раза большим, чем сначала казалось нормальным...)...
И никаких лишних выходов не захотелось бы.

На этом конкретно примере удобнее рассматривать "ошибку", равно как и "останов", как исключительную ситуацию. Потому что в таком виде код понятнее любого из приведенных здесь примеров, при всем уважении к Дейкстре и автоматам.
Буквально вчера реализовывал некую batch-операцию, в процессе которой пользователь может отменить ее. for_each + throw cancel. Никаких злобных WHILE'ов с протаскиванием признака отмены операции (там и без этого достаточно полезного "состояния"). Все просто и понятно. При тестирования нашел только одну ошибку - в форматировании строки сообщения.

Так мы про это уже говорили - понятнее Вам, т.е. вашему пониманию алгоритма. Ваш мозг не ищет для анализа тех свойств, которые нужны моему, и наоборот (я вот не буду в подробностях воображать выполнение, и т.п.).

Речь не о том, как понятнее; а речь о том, какой стиль мышления принять. Затем уже от нотации требуется показывать то, что для этого стиля важно.

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

Лично моё мнение, что двумерные чертежи на ДРАКОНе вполне подходят.

Да, давно хочу попробовать ДРАКОН в деле. Хотя идея генерить "настоящий" код (для традиционных ЯП) на основании драконовских чертежей мне по-прежнему кажется нереальной.

Не согласен. Геометрия пространства ситуаций здесь, так сказать, есть "пересечение двух линий". Пересечение двух линий за двумерное пространство не катит. Короче, задача здесь одномерная и состоит из IF-а вложенного внутрь REPEAT, а бинарную псевдо двумерность Вы внесли сами введя для этого вспомогательную команду empty.

Ну, может быть, что и так

Просто я вообще не привык использовать цикл REPEAT, а если трансформировать его в WHILE, то выносимое до него первое действие слишком длинное... Поэтому я сразу отбросил вариант с IF.

Хотя... IF - это охрана на действие. Выражающая, что действие выполняется не всегда.
В Вашем варианте она выражает, что выполнение Run происходит всегда, кроме, возможно, последнего обращения цикла. Т.е. этот IF внутри цикла нужен только для того, чтобы "подстрогать" на один раз. Что-то мне это напоминает засовывание обрабтки найденного элемента внутрь FOR-IF

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

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

Нет уж, извините. Циклы и Дейкстра к данному примеру "неправильной декомпозиции" вообще никаким боком (иначе бы Александр, как исповедующий именно такой подход, переписал его нормально, а не стал бы перетасовывать ретурны). Скорее уж ООП здесь является главным виновником. Типа, инкапсулируем состояние в классе/рекорде и напишем сто методов, играющих с этим состоянием. Неважно, что этим методы логически никак не связаны друг с другом, они же прописаны в одном классе (связаны с одним рекордом), поэтому создается ощущение (иллюзорное) что все хорошо и логически связано.
А вот увидеть ошибки такого подхода (и избегать их) и получить представление как должно быть по-хорошему помогает функциональное подход. Во всяком случае сужу по себе - после погружения в функциональный стиль программирования (и знакомства с хаскелем, в частности), количество методов классов в моем плюсовом коде резко уменьшилось, так же как и количество непонятно что делающего кода подобного представленному выше примеру.

P.S. К вопросу о тому чему учить в образовательных заведениях. Хоть какой-нибудь функциональный язык обязан присутствовать если не в школьной программе, то в ВУЗовской. И не надо пытаться подменить его обероном, который якобы поддерживает функциональный стиль.

К этому примеру - да, не имеет!
Я просто в очередной раз акцентирую внимание, что стиль построения алгоритмов имеет влияние на разных уровнях системы, а не просто "написали-обернули-забыли-занялись архитектурой".

Про ФП - безусловно. В высшем профильном образовании никто не возражает. Вообще, должен быть обширный курс по разным парадигмам программирования. Без эрудиции никуда.

В школьную программу это за безнадобностью (да если бы и "за надобностью" - это была бы просто маниловщина... ибо там "не до жиру...")

Инсинуации Vladа надоели.

Между прочим, в процессе отладки в цикле выяснился еще один нюанс.

Как это учесть в цикле Дейкстры, который Илья Ермаков написал?

Ну, такой простой вариант, естественно, понятен. Но как-то Дейкстры тут не видать - обычный программистский цикл. А у Ильи получилось совсем классно - с состояниями!
Я Дейкстру, конечно, читал еще тогда. И даже разбирал все доказательства теорем. И даже сам доказывал то, что он оставлял читателю. Но тогда все это воспринималось исключительно с теоретической точки зрения. А сейчас я хочу все эти дела в учебный язык включить, поэтому нужно с практической точки зрения разобраться, в каком виде это может быть в языке.
Как у Мейерса в Эйфеле?

А если Jump будет лежать во второй части слова? Такое предусмотрено?

Если вторая команда, то специально ничего проверять не нужно: цикл просто переходит на проверку условия (а Регистр адреса RA уже новый!).

Что-то я не находил таких статей, где говорилось бы, что Дейкстра любил нагромождать сложности...Я не считаю, что Илья правильно использует этот цикл. Зачем оно надо, если тело выполняется только один раз? Какой же это цикл? Правильнее было бы, конечно, не высказывать своего мнения по поводу цикла Дейкстры, пока толком не разобрался, но...
ближе всего по семантике кА вообще - это цикл, содержащий CASE-подобную конструкцию (или, скорее, даже WITH-подобную), в каждом из вариантов которой присутствует единственный оператор - обычный цикл WHILE. Выбор варианта делается на основе максимально полного соответствия условию подцикла, следующего далее. Количество вариантов должно быть настолько велико, чтобы полностью покрыть условие наружного цикла.