Насчет типа STRING. Почему интересно Вирт не добавил такой тип в язык, ... ?

Здравствуйте, Сергей.
Вы писали, что хорошо бы удалить из Оберона указатели, кроме указателей на записи, и добавили бы тип STRING.
Чем плохи указатели на массивы? Мне кажется что это очень полезный инструмент во многих случаях, когда размер массива изначально не известен. А если выделять сразу максимальный размер для каждого элемента, то может не хватить памяти. К тому же в массиве можно быстро искать с помощью бинарного поиска, а в записях поиск можно делать только последовательно.

Как-то ведь Вирт обошелся без указателей на массив в Обероне-07.

При написании компилятора можно обойтись только указателями на записи. Для массива ключевых слов, например, размер можно задать заранее. Но ведь это не говорит о том, что всегда можно обойтись без динамических массивов.
Можно конечно в записи создать фиксированный массив на 1000 элементов, а если требуется добавить 1001-й элемент в массив, то создать еще одну запись. Но это усложнит алгоритмы для работы с такой структурой.

Чем дальше занимаюсь строками, тем больше понимаю, что подсистема Text (BlackBox) и модуль Texts (Oberon System) - это и есть те самые библиотеки для работы с динамическими строками. Что-то более простое реализовать сложно.

Совсем нельзя. Но насколько часто надо?

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

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

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

Если я не ошибаюсь, то в Обероне-07, который сделан с учётом опыта Оберона-SA, это как-то связано с особенностями целевой платформы StrongARM. Было такое предположение.

Ещё Files.File.

Но дин. массивы представляются всё равно нужными. Мелкий пример - вот хранить неизменяемую, но дополняемую структуру со строками разных длин; удобно эти "хвосты" переменной длины динамически порождать.

Вообще-то Фортран много лет обходился без динамических массивов...
Кроме того, на базе фиксированного массива большого размера можно построить систему распределения памяти. Например, см. Холл "Вычислительные структуры"...

Скажите лучше, что в них плохого?