Оберон-клуб «ВЄДАsoft»

Помню была критика поддержки в оберонах доступа из локальных процедур к локальным переменным уровнем выше. (наверно в сравнении с oberon-07)
А что если делать экспорт локальных переменных в локальные процедуры и/или сделать доступ к ним квалифицированный (т.е. явно указывать из какой процедуры брать переменную)?

Но это ведь характерно только для Оберона-07, где такой доступ выпилен? Я правильно понимаю?

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

Вопрос в дуракоустойчивости, актуальный для любых оберонов поддерживающий доступ к локальным переменным другой функции.
Бывало попадался, что не создал новую переменную и использовал переменную более верхнего уровня когда не надо (забыл/рефакторил), а потом долго искал что же не так. %)

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

Только в Обероне-3 мы с Олегом Комлевым реализовали запрет на использование в FOR переменной с более высокой, чем локальная, вложенностью.

Ограничение на доступ к локальным переменным, принятое в Обероне-07, тоже никак не мешает использовать переменные таким образом, как ты сказал. А вот зачем оно действительно нужно — мне не очень понятно. Надёжности это не очень добавляет. Если хочешь аргументировано поспорить — приводи, пожалуйста, код с твоими пояснениями.

По принципу «разделяй и властвуй» мы должны разбить целое на кусочки и изолировать каждый кусочек, как только возможно. Но кусочки взаимодействуют, поэтому нужно контролировать связи (интерфейс) кусочков. Когда такой кусочек - процедура, ее интерфейс: 1)формальные параметры, 2)возвращаемое значение (для функции) и 3)обращение к внешним сущностям (переменным, константам ,типам, процедурам и пр).
Лучше всего с точки зрения контроля - формальные параметры, потому что они перечислены сразу в заголовке, там указан тип, по ссылке\значению, IN\OUT. Их имена локальны в этой процедуре, поэтому назвать их можно как угодно.
Тип возвращаемого значения тоже задается. В Обероне 7 значение возвращается только в конце – это тоже направлено на больший контроль за связями. RETURN, прекращающий действие процедуры, это «родственник» GOTO. Если нам понадобиться что-то дополнительно сделать перед выходом, придется найти все RETURN во всей процедуре. А в Обероне 7 такой RETURN только один, поэтому нет проблем поставить дополнительные действия перед ним.
А вот с внешними идентификаторами контроль связей наименьший. Называются они так, как они там называются внешне, и это не изменить. Обращаться к ним можно откуда угодно, и единого списка зависимостей нет.
Если забыть объявить идентификатор, то он понимается как внешний, находящийся в ближайшей охватывающей области. Охватывающая область определяется текстуально, а не порядком вызова процедур. В PHP, например, наоборот: глобальные переменные требуется объявить в списке global, а локальные объявлять не требуется.

Кроме того, есть технические сложности с обращением к локальным переменным (или параметрам) внешней процедуры. Ведь они находятся в стеке, поэтому не имеют определенного адреса, в отличие от глобальных переменных модуля. Поэтому требуется специальный механизм фреймов для поиска их местонахождения.
В описании Оберон-07 «The Programming Language Oberon Revision 1.10.2013 / 1.5.2016» в разделе 10 сказано: «In addition to its formal parameters and locally declared objects, the objects declared globally are also visible in the procedure.». В русском переводе от 1.11.2008 https://forum.oberoncore.ru/viewtopic.php?f=115&t=3026 вместо «declared globally» написано «объявленные в окружении процедуры». А что значит «declared globally»? Глобально на самом верхнем уровне (уровне модуля) или «на любом внешнем, охватывающем процедуру»? Вполне возможно, что Вирт хотел открыть доступ изнутри процедуры только к глобальным идентификаторам, чтобы не использовать сложный механизм фреймов.

Итак, предлагается ввести дополнительный контроль за обращением к внешним идентификаторам. Наверно, правильнее назвать это не экспортом, а импортом. Экспорт – некоторый механизм, при помощи которого внешние идентификаторы «выставляются наружу», чтобы их мог кто-то использовать. Импорт – механизм «получения» внешних идентификаторов.
Можно представить в процедуре какой-то «список импорта», чтобы там были перечислены внешние идентификаторы, к которым она обращается. Возможно, с дополнительным механизмом псевдонимов. Это действительно обеспечит дополнительный контроль, но насколько сильно всё усложнит?
Мне представляется, что процедуры должны быть небольшими и «родственными» (работающими с одним контекстом), чтобы в них легко было разобраться, «держа в голове» этот контекст.

Ага, легко сказать «небольшими и несложными», на практике так не получается. Хотя бы для примера, посмотрите, насколько “простые” процедуры для транспиляции “proper FOR”.

А вот на границе модуля есть «контрольно-пропускной пункт» в виде импорта, псевдонимов и квалификации имен. Но может быть нужны какие-то промежуточные «средства контроля»? Что-то вроде списка global в процедурах или составные имена, как предлагалось SovietPony?