OberonCore

стр. 27
Обычно говорят "элемент массива", а не "компонента массива".

стр. 29
В Power передаётся параметр N: INTEGER, но и массив объявлен как ARRAY N OF... В Оберонах размер массива так задать нельзя.

стр. 40-41
В New и Old в DEFINITION имя передаётся по ссылке VAR, а в MODULE ссылочный модификатор испарился. То же самое пропадение VAR перед f в Set. Такое ощущение, что сначала f был RECORD, а потом вдруг его быстренько переколбасили в POINTER TO RECORD, в каких-то местах VAR убрали, а в каких-то забыли.
Имена File, Rider, New, Old, Close, Set, Write, Read, WriteInt, ReadInt должны экспортироваться (и даже имена набраны жирным шрифтом), но не зазвездены.
Так же не зазвездён Rider.eof.
В комментарии Max Length вместо MaxLength.
В процедуре Write: r.pos <= r.s.len вместо r.pos <= r.f.len
В New после NEW(f) делается ненужная инициализация полей у f (после NEW они и так пустые).
В Old осталось за кадром f.len = ?.
Лишняя табуляция перед PROCEDURE ReadInt.
В Set вместо комментария (* предполагается f # NIL *) можно было так и написать ASSERT(f # NIL)

Дальше ещё не читал.

Спасибо, очень полезно.

Говорят мало ли что. "Компонента" -- единое понятие для массива и записи. Это единство (которое по тексту подчеркивается) и хотелось сохранить. Никакой проблемы тут не вижу.

Первая забота была, чтобы в примерах на диске всё работало.
А там, вроде, всё работает.
Разбираться в тонкостях отличий между старым Обероном и Компонентным Паскалем сил тоже не было: кое-что было скопировано из КП только с очевидными заменами (OUT >> VAR и т.п., и то могли остаться опечатки).

Большая проблема была с верстальщиком. Она вручную форматировала программы по pdf-файлу (сходу не припомню, почему у ней rtf не сработал). Отсюда странный пробел в Max Length, лишняя табуляция и т.п. Замыленный глаз этого не видит в принципе (я столько на этот текст смотрел, что просто как слепое пятно).

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

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

Во всяком случае пишите еще!

Еще раз спасибо!

Стал дальше читать, там в буфере имена процедур deposit и fetch выделены жирным, но тоже не зазвездены. Наверное с Паскалевской версии тянется. На стр. 43 вместо "(* реализует кольцевые буфера *)" надо "(* реализует кольцевой буфер *)". Кстати, во множественном числе "буфера" или всё таки "буферы"?

Попробую.

Во всяком случае в оригинале без звезд.
Эти примеры не реализовывались, поэтому.
Наверное, вообще их надо выкинуть.

Помню этот пункт, но не помню, почему в итоге получились "буфера".

может "реализация кольцевого буфера"?

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

Возможно.

На страницах 58 и 63 пример поиска образца Hooligan напечатан немоноширным шрифтом из-за чего нижние строки съехали влево.

Вот это неприятно.

стр 162 "...можно сформулирловать так:"

стр 196 в процедуре tree написано: Texts.ReadInt(R, new.key); new.key := x;
должно быть либо: Texts.ReadInt(R, x); new.key := x;
либо просто: Texts.ReadInt(R, new.key);
В ней же ветвь IF n = 0 THEN new := NIL имеет немного смысла, так как new и так равна NIL в силу умолчальной инициализации, и можно было бы сразу перейти к рассмотрению случая IF n > 0.
В ней же n уменьшается на 1 несколько замысловато, можно бы и явно (но тогда поменять порядок вычисления nr и nl).

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

Процедура PrintTree написана дважды: в первый раз на стр 196-197, а потом ещё раз на стр 201.

стр 203 в пункте списка под номером 2 написано: "Так как длина слов может сильно меняться, их литеры хранятся в особом массиве-буфере, а узлы дерева содержат индекс первой буквы". Но в примере этого особого массива-буфера нет, там просто слова максимум из 31 литеры.

Спасибо, всё отслеживаем.


Это в Компонентном Паскале они выставляются в NIL.
В классическом Обероне этого не было.

Кстати, не Вы ли еще на Королевстве когда-то высказывались, что полагаться на встроенную инициализацию указателей "однозначно плохой стиль" (или как-то так)?

В Обероне этого не может быть, так как нарушает герметичность. Сборщик мусора обрушил бы всю систему на первом же указателе, который случайно забыли проинициализировать. Наверное это тянется с Паскалевской и Модуловской версии книг.

Не помню такого.

Да, всё, похоже, так.

А вот и нет. В Обероне локальные переменные не инициализировались, а сборщик мусора вызывался только в главном цикле.

О причинах этого есть у Шиперски:

стр 216 "мы снова будет заменять"
стр 224 "а также прцедура"
стр 251 упражнение 4.5: странный перенос слова "так". На одной строке "та-", на другой строке "к".

Дочитал до конца, больше опечаток не нашёл. Зато в конце нашёл редактора и корректора: Мовчан Д. А. и Синяева Г. И.

А в NEW память тоже не обнулялась? В книге указатели обнуляются явно даже после NEW.

Большое спасибо. Я бы сказал, очень даже терпимо.

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

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

Я бы не поручился, что это ошибка -- у Вирта есть и другие подобные примеры