OberonCore

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


Нет, Анатолий Иванович, давайте, может, эту фразу не трогать? )) Нам в методиках до неё ещё расти и расти. Т.к. окончание этой фразы у Ершова что-то типа "... с доказательствами, в стиле лучших курсов матанализа".

Недавно на одной задаче, связанной с чтением строки символов неопределенной (но заведомо не пустой!) длины, готовил решение на турбопаскале для нашего турнира. Так для "отсечки" конца строки от последнего символа и простоты условия показалось разумно применить как раз
repeat read(c); <обработка> until eoln;
С while так просто не получилось.


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

Да, я сам вижу на практике, что нужны как минимум два варианта базового курса: для одних групп (будущие программисты) - математичный (этот в этом году удалось построить); для других (будущие инженеры, технари...) - некий другой (в этом году он мне не удался). На самом деле, нужен ещё курс для гуманитариев (тут Фёдор Васильевич получше скажет...).

Но тех, кто метит в программисты, надо сразу "строить по науке". Иного способа нет отсечь ту "пену", которая сейчас дискредитирует название профессии, и которая всем нам доставляет уйму головной боли. Нужно задирать планку. Тогда можно будет чётко говорить: "уважаемый, Вы - не программист, Вы максимум - любитель. А вот - программист."

Анатолий Иванович, но это же базовая схема "полный проход":
взять_первый_элемент;
WHILE ~конец_последовательности DO
обработка;
взять_следующий_элемент
END

Из того, что в данном частном случае взятие первого и следующего элементов выглядят одинаково, ещё не следует что "кажущийся повтор" нужно пытаться укоротить. Пусть так и будет, очевидно, шаблонно и ясно:
Read(c);
WHILE ~eot DO
обработка;
Read(c)
END

Может я что-то упускаю из виду, но по-моему правильно так:

Итого, всё тело цикла продублировано. Нехорошо, на мой взгляд.
Но с другой стороны непонятно, почему в данном примере просто нельзя было использовать WHILE, пускай и заранее известно, что цикл выполняется как минимум раз.

Это не может быть правильно, потому что после Read должна быть проверка.

А перед Read -установка(инициализация). тогда всё намного логичнее:

Что ж, значит я неверно понял смысл "eot". Но если говорить о Турбо Паскале, то функция "eoln" отвечает, есть ли что считывать, а не проверяет, правильно ли прочитался символ при последнем запросе. Поэтому в варианте Ильи Ермакова с функцией "eoln" последний символ строки обрабатываться не будет.

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

К сожалению не помню пытались ли авторы доказать применимость формальных методов для доказательства корректности алгоритмов с такими "структурными переходами".
Практически, наблюдая такой "структурный" код на практике, склоняюсь к тому, что -- нет.
ИМХО, единственный способ выбивания такой дури -- это строгое структурное программирование, например как в Oberon-07.

Имею одно наблюдение.
Использование break (и др.) обосновывается тем, что тело цикла становится короче.
Обычно, приводится пример поиска for-if-break.
И действительно, в таких вырожденных случаях, циклы выходят более короткими, чем их WHILE-аналоги.
Так почему же в результате на практике наблюдаем тела циклов в десятки-сотни строчек, напичканные break и continue?
Настолько ли сложна проблема, что без break никак?

Моя гипотеза: нет.
Т.е. наоборот, break играет дурную шутку.
Заменяя паттерн поиска:через for-if-break или for-if-return, получаем:В WHILE-цикле, блоки поиска (search) и обработки (process) разделены.
В for-цикле, поиск и обработка "слипаются", увеличивая тело цикла.
Практически, не возможно используя break вытащить обработку из тела for-цикла.

Дальше -- больше.
Если в дальнейшем приходится усложнять поиск или добавлять обработку, цикл продолжает жирнеть.
При необходимости добавить дополнительные условия выхода в чужом коде с таким циклом приводят к дополнительным if-break.

Конечно можно обвинять "тупого соседа", но специально акцентирую внимание на процессe развития таких циклов, от маленького и простого, до полотен в несколько страниц.
Этот процесс неизбежен, хотели как лучше (сократить пару строчек в простейшем цикле), получаем в дальнейшем кошмар.

Теперь пару слов о FOR-циклах в Oberon.
На мой взгляд, главная проблема решена -- нет break/EXIT для FOR.
Вторая проблема -- "RETURN из середины процедуры" должна быть как то решена методически.
Т.е. преподавание построить так, что бы начинающему ученику даже в голову не могла прийти такая идея как RETURN из циклов.
Иными словами преподавать Oberon-07.
LOOP-EXIT должны тоже выпасть из образовательного процесса.
Если после всего этого у учеников все еще будут проблемы с применением FOR/WHILE, то вполне возможно, что WHILE должен идти первым.
Т.е. отработать вначале поиск (например, по массиву), и только потом, как некая оптимизация частных случаев, можно представить пробег "по всем".

А вот и нюанс, на которые я намекал, говоря о тонкой оптимизации:
eoln=true мы получим ОДНОВРЕМЕННО с чтением последнего символа строки, который в Вашем варианте алгоритма будет потерян!!
Вот прогнал Ваш вариант в среде Борланд Паскаль (от среды турбопаскаль в этом месте отличий вроде бы нет):
Последний прочитанный символ строки не допускается к обработке, поскольку в while вход уже закрыт!
Мой вариант с repeat этот нюанс учитывает.
В Вашем варианте этот дефект можно разглядеть, если хорошие очки надеть!
В КП/ББ иная картина: вариант с REPEAT "не катит", а с WHILE всё четко:

Но тут разработчики ББ были более точны.
Так что, коллеги, в очередной раз убеждаемся, что в нашем деле за каждой "запятой" надо внимательно следить
Правда, показать полезность REPEAT в КП не получилось

"Тонкая оптимизация" такого рода в учебной программе (и в большинстве профессиональных) -- наказуемая ошибка.

Корректный вариант должен содержать обработку конца цикла.

А Ваш вариант с repeat правильно отработает при попытке чтения пустого файла?

Чем Вам не нравится следующий вариант?

Неправильно. Но я заранее оговорился, что предполагаем файл не пустой!

А может не делать таких предположений? Лучше - грамотную обёртку для чтения текстов в турбике, чтобы было типа In.Done.

Тем, что я не знаю, каково значение eoln ДО первого чтения.

В Справке в BP7 дан пример:
begin writeln(eoln) end.
Программа ждет нажатия клавиш! Если нажимаешь только Enter, получаешь TRUE. Если жмешь символьные клавиши в любом количестве и только потом Enter - получаешь FALSE. Как говорится, "спасибо"! Вам ясно, что будет с первым входом в цикл? Мне - нет.

Вроде как всё очевидно - сразу нажали Enter и первый символ строки имеет код 10, что означает конеw строки, eoln(End of line то есть). а если написали символов - то первый символ строки уже не 10 - вот вам eoln и даёт FALSE. возможно каретка сразу установлена в первый символ.

Я не могу найти где задача.
придумаю сам: прочитать многострочный файл посимвольно(и построчно) и вывести на экран сохраняя структуру переносов строки:

работает. не знаю, поможет или нет.