OberonCore

Мир меняется постоянно, а инварианты остаются. Вот чтобы выжить и быть впереди, а не позади, при постоянных изменениях, нам и надо стараться их ловить, инварианты эти. А то всё подбираем "отрыжки Мелкософтов".

Блин, ну сколько в открытые двери можно ломиться???

Вы читайте, что пишут! Я же говорил, что при отражении модели в языке, нам часто нет необходимости в цикловой переменной.
Есть операции, в которых она ПРОСТО НЕ НУЖНА ПО СМЫСЛУ.
Например (от лихтарыка):
Collection.ForEach и Collection.Find
Это - ЕСТЕСТВЕННОЕ высокоуровневое описание наших намерений относительно как всей коллекции, так и отдельных ея элементов.
Теперь встаёт вопрос о передаче фрагмента действий с элементов этой коллекции.
В простейшем случае можно обойтись ссылкой на процедуру/функцию, в аргументах которой будет "формироваться контекст" при работе с очередным элементом. Но часто бывает удобно и более естественно, передавать туда нечто, что увяжет текущий контекст (в котором вызваны Collection.ForEach и/или Collection.Find) с контекстом самих Collection.ForEach и Collection.Find... Например, кусок кода обращается к локальным переменным процедуры вызывающей Find для сравнения полей элемента коллекции с локальными (и не только!) переменными, которые "текстуально не известны" в Find.
Часто оказывается, что такая запись проще и нагляднее.
Ещё раз повторяю, мы рассматриваем данное средство (относительно ООП) именно, как один из путей удаления лишнего уровня абстракции (семантически несовместимые по уровню абстракции) работы с переменными цикла. Плюс - повышается надёжность, за счёт удаления лишних мест, где можно получить ошибки через описки...

В си-шарпе этим "нечтом" стали "замыкания"...

Относительно решения Вирта о цикле FOR, я сказал, что работа с "массивами" (как с частным случаем классов "коллекций") оказалась "размазанной" по уровням абстракции, благодаря невключению в язык FOREACH.
Кстати, тот же поиск, в случае расширения применения EXIT для всех цикловых операторов, выполнялся и ещё таким способом:

Заметьте, что здесь ошибки быть не может с границами поиска.
Кстати, короче можно было бы записать, введи Вирт (наряду с "для каждого", операцию проверки "а есть ли?"). Но - лишних слов много... Опять-таки "лишнесть" не есть плохо или хорошо. Массив в Оберонах - не расширение какого-то коллекционного типа, в котором описанные мной операции определены, а "собственная сущность и понятие"...

Или

Остаётся тот же вопрос: как это скажется на компиляторе?
Например, Вирт удалил из компилятора для StrongARM даже райдеры массивов, т.к. они "применялись редко". А ведь именно индексация массивов - самое слабое место однопроходного компилятора (вручную не оптимизируешь: у программиста нет другой возможности выразить последовательный проход по массиву, в отличие от Си).
А тут нам предлагаются такие навороты как "замыкания".
Такое впечатление, что в приведённых примерах трудности как раз возникают из-за отказа от переменных цикла. IMHO, единственное, что может к этому подвигнуть, - стремление к обобщению кода. Например, чтобы иметь возможность поменять структуру данных коллекции. Примем это как реальную потребность и посмотрим, что можно сделать, не меняя языка.
Пусть у нас есть коллекция, её метод ForEach и необходимость передать в коллекцию не только процедуру обработки, но и некий контекст вызывающей процедуры.
Есть ли в Обероне для этого средство? Конечно, есть. Это расширяемая запись.
Например, набросок для ББ.
И, пожалуйста, расширяйте сколько угодно тип Guest и передавайте любой нужный вам контекст для обработки элементов коллекции. Просто заводите локальную запись (тип которой - потомок Guest; разумеется, в данном случае нет нужды в дублировании переменных или в использовании динамической памяти - в качестве локальных переменных вызывающей процедуры используем поля записи) и передаёте в ForEach в стиле обероновской программной шины.
Зачем огород городить?

Уважаемые коллеги, но давайте ещё вспомним, что Оберон-языки - это универсальные языки, и даже более с уклоном в системные-инфраструктурные задачи. Это ко многому обязывает и от многого сдерживает.

А в чём там "трудности"?


Да мне, как пользователю коллекции, наплевать на внутреннее представление, поддерживающее (упорядоченную) совокупность моих элементов!
Мне важна функциональность самой коллекции по отношению к элементам, хранимым в ней!


Ну... - и – ЧТО? Мне что вручную теперь:
1) расширять запись полями для каждого из значений, знание о котором я хочу передать в Do?
2) писать свой код, копирующий в эти поля нужные мне значения из нужных переменных окружения в местах вызова Find/ForEach?
В конце концов, у меня ведь могут быть сотни (тысячи!) разновидностей вызовов Find или FortEach... И, к тому же, в – в сотнях (тысячах!) мест вызова, с РАЗЛИЧАЮЩИМИСЯ контекстами (наборами доступных переменных)! Для каждого из случаев прикажите пункты 1) и 2) повторять? Да – ЧУР МЕНЯ!


"Да." (с) птыц Дяди Фёдора.
Может лучше универсальным принципом-подходом-механизмом обойтись?...

Так ведь контекст приходится передавать?

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

Да не нужно ничего копировать!
Просто используем запись как секцию VAR.
Например:

Перменные (их существование) УЖЕ обусловлено задачей. Никакого "принуждения" или добавления "внетемовой" вещи НЕ состоялось. Лишних абстракций и действий не производится. Ваш же вариант добавляет массу "отвлекающих" моментов в коде и в логике разбора чужого кода и сопровождения...

Спасибо, теперь понятно.

Понятно, по-русски не можете. Тем не менее, если вы научитесь русскому языку на русскоязычном форуме, вы будете выглядеть приличнее.

По моему это называется снобизм

По-моему, это называется "отрыв от корней и традиций".
Даже если, наряду с другими англицизмами, и аббревиатура приведена в транслитерации...
Или новому поколению ссылка на гугль понятнее?

Обыкновенное хамство

И лень

Лично я в таких случаях всегда говорю: "Гугл в помощь!"

Не понял, а что среди нас есть "афроамериканцы"? Тоды - звыняйте! ;о)

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

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

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

Угу. А учитывая, что некий объект из проблемной области на Хаскеле может быть смоделирован с помощью функции, то можно прийти к выводу, что наш Geniepro - тоже функция. Разве нет?

Да все мы в Матрице живём...