Предлагаю к спокойному обсуждению на перспективу вот что.

КП, наследуя в этом Оберону, чётко определяет: сначала секция объявлений, потом процедуры, при этом принцип предобъявлений сигнатур. Всё сделано для однопроходной компиляции с прямой кодогенерацией - в классическом Обероне.
Ценность этого для мини-языка и тем более обучающего курса - огромна. Однопроходный компилятор, действительно, влезает на несколько страниц книги "Проект Оберон".

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

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

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

Вложение:
Снимок экрана от 2018-11-21 13.54.01.jpeg [ 44.35 КБ | Просмотров: 12318 ]


Но процедурные объявления пока жёстко отделены в секцию процедур.

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

Т.е. просто разрешением чередования объявлений и процедур мы бы снимали "малой кровью", без изменения основной грамматики языка, то, что в Активном Обероне, Зонноне и др. вообще "решено" по мейнстримному: всовыванием методом между RECORD/OBJECT и END.

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

Мы много обсуждали на прошедшей конференции песпективы построения над КП/ББ предментно-ориентированных инструментов, с высокоуровневыми описаниями.

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