Автор Тема: [Oberon 07/13] Семантика FOR  (Прочитано 18390 раз)

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re: [Oberon 07/13] Семантика FOR
« Ответ #30 : Декабрь 03, 2013, 03:58:46 pm »
В результате замены операторов FOR на процедуры получим:

Для меня это выглядит как искусственное дробление единого контекста. И это все ради пространств имен и прочей методологии?

А заводить переменную цикла тут же в FOR будет не проще, не?
Будет методологически неправильней. Почему в операторном теле процедуры должны быть какие-то декларации?

А почему нет?

В паскалевских ЯП декларативная область отделена от операторной. Иначе мы получим язык Дейкстры, где у каждого вызываемого оператора свое пространство имен. Операторы не должны вводить новых сущностей или менять свойства уже существующих, их дело работать с тем что уже есть.

Почему? Особенно если речь идет о локальных переменных. Которые по сути своей - регистры для временных значений, не несущие никакой декларативной нагрузки.

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

Не-не. Не передергивай. С сущностями все хорошо, они одни и те же и с одним смыслом. Речь идет лишь о пространстве имен отдельного оператора - почему это плохо я не понял.

ddn

  • Jr. Member
  • **
  • Сообщений: 59
    • Просмотр профиля
Re: [Oberon 07/13] Семантика FOR
« Ответ #31 : Декабрь 06, 2013, 10:56:25 am »
В результате замены операторов FOR на процедуры получим:
Для меня это выглядит как искусственное дробление единого контекста. И это все ради пространств имен и прочей методологии?
Да!

А заводить переменную цикла тут же в FOR будет не проще, не?
Будет методологически неправильней. Почему в операторном теле процедуры должны быть какие-то декларации?
А почему нет?
Потому что в паскалях так принято.

В паскалевских ЯП декларативная область отделена от операторной. Иначе мы получим язык Дейкстры, где у каждого вызываемого оператора свое пространство имен. Операторы не должны вводить новых сущностей или менять свойства уже существующих, их дело работать с тем что уже есть.
Почему? Особенно если речь идет о локальных переменных. Которые по сути своей - регистры для временных значений, не несущие никакой декларативной нагрузки.
Любые переменные в паскалях объявляются, то есть имеют декларативную нагрузку. Но дело здесь не в этом, счетчик FOR тоже объявляется, в самом FOR или вне его. Локальные переменные объявляются во вложенной (локальной) области видимости, но тоже в ее декларативной части. Не следует объявлять идентификаторы в операторах.
Скрытые регистры присутствуют в операторах и выражениях, но они всегда безымянные.

А если в теле процедуры в одном месте действуют одни сущности, в другом другие, или одна и та же используется с разным смыслом в разных местах, то это основание, чтобы вывести такие участки в подпроцедуры.
Не-не. Не передергивай. С сущностями все хорошо
Сущность в данном случае, это идентификатор-счетчик который в операторе FOR либо вводиться, либо меняется с var на read only.
они одни и те же и с одним смыслом.
А какой смысл имеет счетчик вне FOR? Либо никакого, либо использется для других целей.
Речь идет лишь о пространстве имен отдельного оператора - почему это плохо я не понял.
Потому что в паскалях не принято делать пространства имен для отдельного (вызова) оператора. Все объявления идут перед началом операторного тела процедуры, модуля или программы.



http://46.254.16.186/oberon@conference.jabber.ru/2013/12/03.html
Цитировать
[19:38:03] <vlad2> Мне кажется товарищ ddn из лагеря драконоидов...
Почему драконоид? Я обычный паскалист.
Цитировать
[19:39:29] <vlad2> Вот я помню в универе писал вычисление детерминанта и не помню, чтоб там было 5 вложенных циклов...
И еще два WHILE. Эту функцию за 10 минут я переписал с ее версии под Мапл. Там нет 5 вложенных друг в друга FOR. Там две пары FOR, где в каждой паре FORы вложены.
Причем одна пара вложенных FOR используется для предварительной перезаписи матрицы в локальную матричную переменную, чтобы не изменять внешний параметр. Максимальня глубина вложенности там 3, что логично, так как метод Гаусса имеет сложность O(n^3) умножений. Алгоритм можно упростить (ценой лишних присваиваний) и убрать одиночный FOR.
Цитировать
[19:47:02] <alexey.veselovsky> не, ну ведь он говорит наоборот - плохо если FOR меняет область видимости
[19:47:08] <alexey.veselovsky> а он, в Обероне, НЕ МЕНЯЕТ!
И это ошибочая реализация логики FOR оператора. Что останется от специфики FOR, если в его теле значение счетчика будет коверкаться как угодно? Но модифицировать область видимости, вводя локальную IN-переменную или запрещая меняться внешней (по отношению к FOR) переменной, тоже нельзя, это нарушение паскалевской методологии. Значит или переводить FOR в процедурную форму, или полностью изгнать с позором этот рассадник греха и порока из райских кущь Оберона.

Geniepro

  • Hero Member
  • *****
  • Сообщений: 1955
  • Знайте- истина в том, что повторено трижды подряд!
    • Просмотр профиля
Re: [Oberon 07/13] Семантика FOR
« Ответ #32 : Декабрь 06, 2013, 11:19:51 am »
И это ошибочая реализация логики FOR оператора. Что останется от специфики FOR, если в его теле значение счетчика будет коверкаться как угодно? Но модифицировать область видимости, вводя локальную IN-переменную или запрещая меняться внешней (по отношению к FOR) переменной, тоже нельзя, это нарушение паскалевской методологии. Значит или переводить FOR в процедурную форму, или полностью изгнать с позором этот рассадник греха и порока из райских кущь Оберона.

Однозначно изгнать! Вместе с расширяемыми записями, ведь их в паскале тоже не было!
to iterate is human, to recurse, divine

Салат «рекурсия»: помидоры, огурцы, салат…

valexey_u

  • Hero Member
  • *****
  • Сообщений: 3013
    • Просмотр профиля
Re: [Oberon 07/13] Семантика FOR
« Ответ #33 : Декабрь 06, 2013, 11:37:37 am »
И это ошибочая реализация логики FOR оператора. Что останется от специфики FOR, если в его теле значение счетчика будет коверкаться как угодно? Но модифицировать область видимости, вводя локальную IN-переменную или запрещая меняться внешней (по отношению к FOR) переменной, тоже нельзя, это нарушение паскалевской методологии. Значит или переводить FOR в процедурную форму, или полностью изгнать с позором этот рассадник греха и порока из райских кущь Оберона.

Однозначно изгнать! Вместе с расширяемыми записями, ведь их в паскале тоже не было!
И сборщик мусора пусть с собою прихватят!
Y = λf.(λx.f (x x)) (λx.f (x x))

ddn

  • Jr. Member
  • **
  • Сообщений: 59
    • Просмотр профиля
Re: [Oberon 07/13] Семантика FOR
« Ответ #34 : Декабрь 06, 2013, 12:09:45 pm »
http://oberspace.dyndns.org/index.php/topic,593.msg20090.html
NEW(C, n, n);
For1(1, n);
Здесь, в варианте функции с FOR процедурами, у меня ошибка.

Должно быть:
NEW(C, n, n);
For1(0, n - 1);

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re: [Oberon 07/13] Семантика FOR
« Ответ #35 : Декабрь 06, 2013, 03:48:43 pm »
Для меня это выглядит как искусственное дробление единого контекста. И это все ради пространств имен и прочей методологии?
Да!

Это очень настораживает.

Потому что в паскалях так принято.

А это подтверждает опасения: http://pritchi.livejournal.com/92886.html
У нас тут главное отличие от оберонкора вовсе не в матюгах, а в том, что критической проверке подвергается все, даже то, что сам сам Вирт назвал правильным. И не ради критики, а ради поиска лучшего.

Возвращаясь к нашим баранам. Зачем иметь локальные переменные в отдельной декларативной части? Есть какие-нибудь формальные причины, кроме "здесь так заведено"?

Цитировать
[19:38:03] <vlad2> Мне кажется товарищ ddn из лагеря драконоидов...
Почему драконоид? Я обычный паскалист.

У драконоидов обычно сильно смещенное восприятие программерской реальности. Из-за этого порой очень трудно понять суть описываемых ими проблем и их возможное решение.

P.S. Про "райские кущи" - зачет, понравилось :)