Oberon space
General Category => Общий раздел => Тема начата: ilovb от Апрель 26, 2012, 11:22:30 am
-
Знаю, что уже обсуждалось неоднократно :)
Но что мешает заменить FOR на FOR EACH?
Я на практике FOR использую очень редко. В основном пишу через WHILE, а если нужно весь массив (коллекцию) обойти, то использую форыч.
Правда не понятно как должна работать связка Oberon+for each+итераторы ???
Кто что думает на этот счет?
-
ИМХО - форич имеет смысл вводить когда в языке много встроенных контейнеров и есть привязка к более менее общим задачам -в O7 только массивы... множества также усечены... диапазонного типа нет- к чему его в ОБЩЕМ случае привязывать? Фор хорош тем, что при правильной реализации заголовок вычисляется ровно один раз со всеми приятными следствиями из этого... а в O7 это пародия на него (косметика над вайл).
-
ИМХО - форич имеет смысл вводить когда в языке много встроенных контейнеров и есть привязка к более менее общим задачам -в O7 только массивы... множества также усечены... диапазонного типа нет- к чему его в ОБЩЕМ случае привязывать? Фор хорош тем, что при правильной реализации заголовок вычисляется ровно один раз со всеми приятными следствиями из этого... а в O7 это пародия на него (косметика над вайл).
В ObjC из встроенных контейнеров только сишный массив. А форыч есть и работает по любым библиотечныхм (или тобою писанным) контейнерам. Аналогично с c++, c#, java, go.
-
Наверно это мои личные предпочтения. :) Но я не знаю в каких случаях FOR лучше WHILE. На мой взгляд WHILE всегда удобнее, кроме случая когда нужно обойти ВЕСЬ массив. А для этого форыча достаточно. Да и по самому форычу визуально сразу понятно, что обходится весь массив.
-
Да ну... :D вы хотите сказать, что если я создам граф произвольной структуры, то с помощью него можно его обойти ? ;D
-
Наверно это мои личные предпочтения. :) Но я не знаю в каких случаях FOR лучше WHILE. На мой взгляд WHILE всегда удобнее, кроме случая когда нужно обойти ВЕСЬ массив. А для этого форыча достаточно. Да и по самому форычу визуально сразу понятно, что обходится весь массив.
while слишком общая управляющая конструкция, следовательно она не выразительна. Поэтому я там где это возможно от while избавляюсь. Далее там где возможно избавляюсь и от for'ов, и максимально остаются форычи.
-
Да ну... :D вы хотите сказать, что если я создам граф произвольной структуры, то с помощью него можно его обойти ? ;D
Да, если он будет удовлетворять некому интерфейсу (и при этом не будет глючить :-) )
-
Да ну... :D вы хотите сказать, что если я создам граф произвольной структуры, то с помощью него можно его обойти ? ;D
Да, если он будет удовлетворять некому интерфейсу (и при этом не будет глючить :-) )
Тьфу на болтуна :), тьфу.. на провокатора
-
Тут valexey должен закричать "Клеветы!!!"(с) ;D
-
Наверно это мои личные предпочтения. :) Но я не знаю в каких случаях FOR лучше WHILE. На мой взгляд WHILE всегда удобнее, кроме случая когда нужно обойти ВЕСЬ массив. А для этого форыча достаточно. Да и по самому форычу визуально сразу понятно, что обходится весь массив.
Фор удобен , когда алгоритм подразумевает выполнение последовательности инструкций (тело цикла) известное (вычисляемое) количество раз (обход элементов из некоторого множества )- и это количество не зависит от тела цикла.. форич это подмножество фора - для алгоритмов в которых не важен порядок обхода... коряво конечно..но лень формулировать точнее...
-
Я такое определение не первый раз слышу :)
Вот только на практике себе это представить не могу. Не встречалось мне такое ни разу.
Можете пример привести?
-
Наверно это мои личные предпочтения. :) Но я не знаю в каких случаях FOR лучше WHILE. На мой взгляд WHILE всегда удобнее, кроме случая когда нужно обойти ВЕСЬ массив. А для этого форыча достаточно. Да и по самому форычу визуально сразу понятно, что обходится весь массив.
Фор удобен , когда алгоритм подразумевает выполнение последовательности инструкций (тело цикла) известное (вычисляемое) количество раз (обход элементов из некоторого множества )- и это количество не зависит от тела цикла.. форич это подмножество фора - для алгоритмов в которых не важен порядок обхода... коряво конечно..но лень формулировать точнее...
Если контейнер, по которому итерируемся, ленивый, то число итераций будет неизвестное количество раз :-) Более того, в этом случае форыч может быть бесконечным :-)
-
угу именно по этому я консервативен по отношению к смешению стилей.. но...тут ведь главное "не стать этаким вот музеем..." и даже "в нужный момент пойти ко дну" возражений не вызывает...
-
Сейчас сделал поиск FOR в исходниках ЧЯ.
90% случаев примерно такие:
FOR k := 0 TO LEN(reeds)-1 DO
NEW(reeds[k]);
Strings.IntToString(k+1, s);
res := reeds[k].Init(0, 0, SHORT("Samurai/Rsrc/reed"+s+".png"));
reeds[k].repeatCount := 10
END;
Т.е. практически везде форыч
-
Сейчас сделал поиск FOR в исходниках ЧЯ.
90% случаев примерно такие:
FOR k := 0 TO LEN(reeds)-1 DO
NEW(reeds[k]);
Strings.IntToString(k+1, s);
res := reeds[k].Init(0, 0, SHORT("Samurai/Rsrc/reed"+s+".png"));
reeds[k].repeatCount := 10
END;
Да, в 90 процентах случаев тьюринг-полнота не используется, являясь лишь источником ошибок.
Т.е. практически везде форыч
Да, в 90% случаев тьюринг-полнота не нужна и не используется, являясь лишь источником ошибок.
-
Я такое определение не первый раз слышу :)
Вот только на практике себе это представить не могу. Не встречалось мне такое ни разу.
Можете пример привести?
Это потому что еще не задумывались об этом....Пример - действия с массивом в котором элементы УПОРЯДОЧЕННЫ - и действия учитывают эту упорядоченность (явно) -
иными словами вам ВАЖНО чтобы элементы массива перебирались, например, в порядке возрастания....
-
Так это как раз исключение имхо, которое спокойно пишется через WHILE.
-
Вы нифига не читаете... :(
-
любой цикл (в императивном алгоритме) можно представить с помощью аналога вайла... речь не об этом...
-
Да я понял о чем вы говорите. Но приведенный вами случай очень редкий. (мне вообще не встречался) Зачем под него держать конструкцию FOR?
-
за тем что она привязана не к контейнеру - а к множеству значений итератора....
-
Наверно это мои личные предпочтения. :) Но я не знаю в каких случаях FOR лучше WHILE. На мой взгляд WHILE всегда удобнее, кроме случая когда нужно обойти ВЕСЬ массив. А для этого форыча достаточно. Да и по самому форычу визуально сразу понятно, что обходится весь массив.
Фор удобен , когда алгоритм подразумевает выполнение последовательности инструкций (тело цикла) известное (вычисляемое) количество раз (обход элементов из некоторого множества )- и это количество не зависит от тела цикла.. форич это подмножество фора - для алгоритмов в которых не важен порядок обхода... коряво конечно..но лень формулировать точнее...
Кстати, порядок форыч вроде как гарантирует (ибо он тупой до безобразия. по сути порядком там командует чисто сам контейнер). Его не гарантирует parallel for. Так что одно с другим путать не надо :-)
С помощью форыча отлично обходятся отсортированные массивы в нужном порядке. Собственно так их и обхожу.
-
В WHILE порядок перебора даже лучше видно на мой взгляд.
Оператор
FOR v := beg TO end BY step DO statements END
эквивалентен следующему
temp := end; v := beg;
IF step > 0 THEN
WHILE v <= temp DO statements; v := v + step END
ELSE
WHILE v >= temp DO statements; v := v + step END
ENDhttp://www.inr.ac.ru/~info21/cpascal/cp_report_1.4_rus.htm#9.8 (http://www.inr.ac.ru/~info21/cpascal/cp_report_1.4_rus.htm#9.8)
-
Наверно это мои личные предпочтения. :) Но я не знаю в каких случаях FOR лучше WHILE. На мой взгляд WHILE всегда удобнее, кроме случая когда нужно обойти ВЕСЬ массив. А для этого форыча достаточно. Да и по самому форычу визуально сразу понятно, что обходится весь массив.
Фор удобен , когда алгоритм подразумевает выполнение последовательности инструкций (тело цикла) известное (вычисляемое) количество раз (обход элементов из некоторого множества )- и это количество не зависит от тела цикла.. форич это подмножество фора - для алгоритмов в которых не важен порядок обхода... коряво конечно..но лень формулировать точнее...
Кстати, порядок форыч вроде как гарантирует (ибо он тупой до безобразия. по сути порядком там командует чисто сам контейнер). Его не гарантирует parallel for. Так что одно с другим путать не надо :-)
С помощью форыча отлично обходятся отсортированные массивы в нужном порядке. Собственно так их и обхожу.
Алексей ну не путайте ТУПУЮ РЕАЛИЗАЦИЮ с ПРИНЦИПИАЛЬНОЙ НЕОПРЕДЕЛЕННОСТЬЮ :(
-
В WHILE порядок перебора даже лучше видно на мой взгляд.
Оператор
FOR v := beg TO end BY step DO statements END
эквивалентен следующему
temp := end; v := beg;
IF step > 0 THEN
WHILE v <= temp DO statements; v := v + step END
ELSE
WHILE v >= temp DO statements; v := v + step END
ENDhttp://www.inr.ac.ru/~info21/cpascal/cp_report_1.4_rus.htm#9.8 (http://www.inr.ac.ru/~info21/cpascal/cp_report_1.4_rus.htm#9.8)
Все хватит... дело не в виде... а в том что в ГРАМОТНОЙ реализации заголовок фор вычисляется ОДИН раз... - в оберонах, как я уже сказал фор - всего лишь синтаксический сахар...
-
Кстати, порядок форыч вроде как гарантирует (ибо он тупой до безобразия. по сути порядком там командует чисто сам контейнер). Его не гарантирует parallel for. Так что одно с другим путать не надо :-)
С помощью форыча отлично обходятся отсортированные массивы в нужном порядке. Собственно так их и обхожу.
Алексей ну не путайте ТУПУЮ РЕАЛИЗАЦИЮ с ПРИНЦИПИАЛЬНОЙ НЕОПРЕДЕЛЕННОСТЬЮ :(
Ок. Если рассуждать формально, то для начала неплохо бы дать определение цикла foreach. Четкое, точное, математичное. И уже от этого плясать. Потому как до того шел разговор исключительно о том как конкретно реализованы конструкции которые называются "foreach" во всеких разных ЯП.
-
Да запросто... выполнить некоторую последовательность действий для каждого элемента из множества, элемент берется один раз, выбор элемента произволен..... надеюсь, что это определение доступно для понимания :(.
-
.... Потому как до того шел разговор исключительно о том как конкретно реализованы конструкции которые называются "foreach" во всеких разных ЯП.
Нет , речь не шла о том, как ФОР или ФОРИЧ реализованы (или нет) в КОНКРЕТНОМ КОМПИЛЯТОРЕ оберона... а о смысловой нагрузке которую он может или должен нести... в терминах AlexUsa- о семантической нагрузке (в Оберонах она минимальна из возможных).
-
The for statement
FOR v := beg TO end BY inc DO S END
is, if inc > 0, equivalent to
v := beg; lim := end;
WHILE v <= lim DO S; v := v + inc END
and if inc < 0 it is equivalent to
v := beg; lim := end;
WHILE v >= lim DO S; v := v + inc END
end вычисляется лишь единожды и запоминается во временной переменной. Где тут синтаксический сахар только?
-
В том, что Вайл по определению вычисляется каждый раз (перед каждой итерацией)... все...
-
А FOR - один раз.
-
форич это подмножество фора
Вы что-то путаете... Согласно вашем же определениям, фор - это подмножество форича. То есть, фор - это форич с определённым ограничением.
-
А FOR - один раз.
В смысле, что язык не накладывает ограничение на реализацию.
-
А FOR - один раз.
да, но проблема не столько в этом - а в том, что в теле цикла (при обероновской реализации) -вы можете изменить значение итератора (и таким образом, повлиять на количество итераций)...- то есть он небезопасен.... или так - уровень безопасности такой же как у вайл
-
Кстати, однократное вычисления ограничителя в форе - это лишь полезная оптимизация, на которую все полагаются. Её обязательное наличие с концептуальной точки зрения (и по виду выражения) не требуется. Её наличие требует прагматика.
-
да, но проблема не столько в этом - а в том, что в теле цикла (при обероновской реализации) -вы можете изменить значение итератора...- то есть он небезопасен.... или так - уровень безопасности такой же как у вайл
Помню, в универе я такое проделывал и в делфи. То есть, думаю, что это патология цикла фор. В любом языке, где он реализован.
-
да, но проблема не столько в этом - а в том, что в теле цикла (при обероновской реализации) -вы можете изменить значение итератора...- то есть он небезопасен.... или так - уровень безопасности такой же как у вайл
Помню, в универе я такое проделывал и в делфи. То есть, думаю, что это патология цикла фор. В любом языке, где он реализован.
Есть разные версии Паскаля... в том же Pabce если в попытаетесь что то засандалить в итератор в теле цикла ... то будет сгенерировано исключение времени компиляции - декларированное языком ИМХО Правильный выбор
-
ИМХО Правильный выбор
Не спорю.
-
форич это подмножество фора
Вы что-то путаете... Согласно вашем же определениям, фор - это подмножество форича. То есть, фор - это форич с определённым ограничением.
Да вы правы... если строго определять... но есть позиция практикующего...когда есть алгоритм (решение задачи)... и есть проблема выбора адекватной конструкции это на "примитивном" уровне, на более крутом... обычно встает вопрос так -есть идея алгоритма- в какую оптимальную форму ее облечь - тут параметры "оптимизации" могут ИМХО приводить к нестандартным взглядам(семантика родственна задаче и вашему взгляду на нее-то есть любая исследовательская (научная) задаче может породить(а может и нет) нестандартное толкование).... но скажу честно... серьезно этой тематикой я не занимался. так что... считаем что вы правы :) :D
-
ИМХО Правильный выбор
Не спорю.
:) Вы выделили не то что определяет - определяющим было декларирование этой особенности на уровне ЯП. Тут возникает известная проблема, с какой точностью должен быть описан ЯВУ... помнится тут на эту тему развлекался Алексей :D ;)
-
Алексей ну не путайте ТУПУЮ РЕАЛИЗАЦИЮ с ПРИНЦИПИАЛЬНОЙ НЕОПРЕДЕЛЕННОСТЬЮ :(
Принципиальная неопределенность foreach чаще всего не нужна. Даже наоборот, чаще всего нужен определенный (тупой) порядок.
"Чаще всего" - относится, конечно, непосредственно к кодированию алгоритма на обычном ЯП для обычных компов. Для каких-нибудь математических рассуждений "чаще всего" может быть совсем даже другим.
-
И я про это ;D - вот фор и задает эту определенность в явном виде
-
И я про это ;D - вот фор и задает эту определенность в явном виде
Эту определенность можно и так декларировать для foreach в конкретном ЯП. Что и делают. Если у вас для foreach подобная декларация кажется неправильной (противоречащей истинной природе "настоящего" foreach) - это ваши проблемы, не используйте такой неправильный ЯП :)
Что касается for'а, то у него полно недостатков даже по сравнению с таким "неправильным" foreach. Поэтому не надо отправлять использовать for там где хоршо работает "непрвильный" foreach :)
-
ну есть например такая распространенная форма foreach i in [1..10] do.... то есть значение i пробегает все элементы из множества... в каком месте здесь есть намек на порядок?
-
или вы поступаете как предлагал Алексей - реализуете форич интерфейс для бинарного дерева... в каком месте там будет указан порядок обхода?
-
ну и совсем смешно не использовать ЯП из за какого то "форыча" ;)
-
и совсем тупо использовать ЯП только по тому, что там есть правильный форич ;D
-
ну есть например такая распространенная форма foreach i in [1..10] do.... то есть значение i пробегает все элементы из множества... в каком месте здесь есть намек на порядок?
Намёк вот тут:
[1..10]
Такая запись означает некий контейнер (список, например), элементы которого упорядочены и возрастают (в данном случае):
[1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
-
ну есть например такая распространенная форма foreach i in [1..10] do.... то есть значение i пробегает все элементы из множества... в каком месте здесь есть намек на порядок?
Намёк вот тут:
[1..10]
Такая запись означает некий контейнер (список, например), элементы которого упорядочены и возрастают (в данном случае):
[1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
фиговый намек... :D например в Паскале эта конструкция соответствует множеству... а в СТАНДАРТЕ языка множества не упорядочены... так что даже если это
и выполняется - то означает вы сели неявным образом на зависимость от конкретной реализации компилятора.. не мне вам говорить к чему это приводит...
-
А если, за такой записью прячется ассоциативный контейнер?
-
А если, за такой записью прячется ассоциативный контейнер?
Обычно за такой записью прячется банальный список (возможно ленивый). Либо тупо range.
-
если список, то... боюсь что, это будет так.. в порядке заполнения....
-
Ссылочка для связи:
Про необходимость for(each) (http://oberspace.dyndns.org/index.php/topic,177.0.html)