OberonCore

Да нет, в книге вирта, даже сортировка пузырьком неудобочитаема. Да и компилятор тоже не архисложная вещь. Обычный синтаксический спуск. Кодогенерация в принципе тоже не архисложная. Однако слабочитаемо. Вот компилятор Свердлова, который в книжке, существенно более читабелен (правда он и попроще).

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

Александр Ильин
Спасибо!

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

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

Может быть люди по психо-физиологическим особенностям делятся на два лагеря. Первые по названиям сущностей ловят смысл, а вторые больше по циклам/ветвлениям и т.д., то есть действиям. Модуль ассоциативных массивов - вещь тоже не тривиальная, но почему его нужно кодировать иероглифами, я не знаю. Да и вообще. Как можно подменять сущность, которая сама говорит за себя (вызывает нужные ассоциации) абсолютно не связанной закорючкой (читать: буквой) a, b, c ,r и т.д., так, чтобы от взгляда на переменную программист понимал, что ничего не понимает и должен в очередной раз возвращаться к объявлениям. Чужеродная ассоция a => array of integer, b => current pos не сразу сложится и потребует вдумчивого чтения, а после забудется (в новой процедуре - новые правила).


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


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

Во-первых, семантика цикла: найти такую рядом стоящую пару p1, p2, что t - между ними. Явное объявление этой пары, как двух переменных, - это правильно. (Определение пары в расширенном смысле, включая пары, один из компонентов которых - несуществующая страница).
Отсюда - совершенно очевидный цикл: последовательный перебор пар, пока не обнаружена подходящая пара или не упёрлись в конец последовательности (да, да, само собой получился "линейный поиск", увы, я не виноват, что семантика цикла такая).

Выкладки же с постусловиями относятся не к циклу, а к IF-ам после. Чтобы разобраться, как после цикла интерпретировать граничные случаи (p1 = NIL или p2 = NIL).

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



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

В этом и состоит Ваша ошибка. Семантика цикла состоит в том чтобы найти ровно ОДНУ нужную страницу, а не пару.

А если rd.base.first = NIL?

Это исключено, при инициализации размещается одна страница. Посмотрите на весь код повнимательнее. А если бы этого не было, то нужно было бы сделать.

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



Проектируя сверху вниз, естественно сразу ввести (ещё до каких-то циклов) эти p1 и p2, а затем цикл построить с ними же. Цикл с парой переменных, хранящих "соседние" значения, вполне общепринят, как в тех же последовательностях аля Фиббоначчи. Т.е. из нисходящего проектирования всё естественно вылезло.

При другом смысле процедуры в голову пришёл бы и Ваш вариант.

Тогда еще двойка за выбор имен! Не SetPos, а что-нибудь типа ReadLastTwo надо было.

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

Просто схема использования Reader всё-таки стандартная для потокового чтения.
SetPos - получили первую пару, относительно примерно указанного t.
Дальше Read - двигаемся по фактически имеющимся замерам.

Таким образом, снова продиктовано "нисходящим образом".

"Ошибки или дефекты, вызванные применением метода программирования "сверху-вниз", не являются ошибками и дефектами".

На самом деле "сверху-вниз" тут вообще не при чем. Просто при поиске был мусор в голове – не было четко определено, что, все-таки, ищем – одну позицию или некую "пару". Но при попытке сформулировать инвариант цикла весь мусор бы автоматически выдуло ветром.