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

Твердыня модульных языков
Текущее время: 05 июл 2022, 17:30

Часовой пояс: UTC + 2 часа




Начать новую тему Ответить на тему  [ Сообщений: 6 ] 
Автор Сообщение
 Заголовок сообщения: Экспорт локальных переменных
СообщениеДобавлено: 18 дек 2021, 15:05 
Не в сети
Аватара пользователя

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

Код: "OBERON"
  1. MODULE Interp;
  2.  
  3. PROCEDURE Call* (IN s: ARRAY OF CHAR);
  4. VAR i: INTEGER;
  5.  
  6. PROCEDURE SkipSpaces;
  7. VAR ch: CHAR;
  8. BEGIN
  9. ch := s[i]; (* ошибка? предупреждение? или разрешить доступ без квалификатора когда объект экспортирован(помечен как "*" или "-")? *)
  10. WHILE (ch # 0X) & (ch <= " ") DO
  11. INC(Call.i); ch := Call.s[Call.i]
  12. END
  13. END SkipSpaces;
  14.  
  15. BEGIN
  16. i := 0;
  17. ...
  18. END Call;
  19.  
  20. END Interp.


Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: Экспорт локальных переменных
СообщениеДобавлено: 19 дек 2021, 10:02 
Не в сети
Аватара пользователя

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

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


Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: Экспорт локальных переменных
СообщениеДобавлено: 25 дек 2021, 22:51 
Не в сети
Аватара пользователя

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


Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: Экспорт локальных переменных
СообщениеДобавлено: 27 дек 2021, 18:44 
Не в сети
Аватара пользователя

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

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

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


Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: Экспорт локальных переменных
СообщениеДобавлено: 06 янв 2022, 10:52 
Не в сети
Администратор
Аватара пользователя

Сообщения: 273
Откуда: Россия
По принципу «разделяй и властвуй» мы должны разбить целое на кусочки и изолировать каждый кусочек, как только возможно. Но кусочки взаимодействуют, поэтому нужно контролировать связи (интерфейс) кусочков. Когда такой кусочек - процедура, ее интерфейс: 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»? Глобально на самом верхнем уровне (уровне модуля) или «на любом внешнем, охватывающем процедуру»? Вполне возможно, что Вирт хотел открыть доступ изнутри процедуры только к глобальным идентификаторам, чтобы не использовать сложный механизм фреймов.


Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: Экспорт локальных переменных
СообщениеДобавлено: 06 янв 2022, 11:17 
Не в сети
Администратор
Аватара пользователя

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

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

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


Вернуться к началу
 Профиль  
Ответить с цитатой  
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 6 ] 

Часовой пояс: UTC + 2 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Создано на основе phpBB® Forum Software © phpBB Group
© VEDAsoft Oberon Club