Обсуждение действительно несколько вышло за пределы только FOR Оберона-7, в том числе и с моей подачи. Кстати, я вспомнил, что несколько лет назад мне тоже приходили в голову мысли
о трактовке неопределенности переполнения в цикле FOR.
Пусть даже так, пусть правильный FOR - одна из возможных реализаций стандартного FOR, имеющего неопределенность. Но встает вопрос: а зачем эта неопределенность нужна?
Неопределенность деления на ноль, например, вытекает из самой моделируемой предметной области - природы чисел.
Неопределенность поведения цикла FOR при изменении переменной цикла вручную - это предостережение программисту так не делать. И полезный эффект от этой неопределенности в том, что компилятор может реализовать механизм наиболее эффективным образом.
Неопределенность может быть связана с техническими сложностями при получении более определенного результата. Например, функция F(N), указывающая с какого знака после запятой десятичная запись этого числа без незначащих нулей встречается в 10-м разложении числа Пи. Для некоторых чисел этот результат легко было указать даже в античные времена, для некоторых получен совсем недавно (F(123456789)=17387594881), а для некоторых чисел (причем не самых больших) не определен до сих пор. Не определен потому, что это связано с техническими сложностями.
А вот почему в стандартном FOR присутствует неопределенность? Причем явно она не оговорена, на нее наталкиваются с удивлением.
Она туда введена специально, для достижения какого-то полезного эффекта, чтобы каждый мог реализовать компилятор наиболее эффективным способом? Не похоже, ничего полезного в зависании при некоторых параметрах нет (пусть даже один из вариантов неопределенности - отсутствие такого зависания).
Эта неопределенность присутствует в самой природе моделируемых сущностей? Опять-таки нет: если заданы все параметры цикла, то четко задана и вся последовательность чисел для которой нужно выполнить тело цикла. Причем, эта последовательность (может быть пустая) определена для любых сочетаний beg,end,inc принадлежащих заданному целому типу.
Может быть запредельно сложно реализовать "всюду определенный" FOR? Ну конечно, стандартный FOR с обязательным инкрементом а-ля С реализовать гораздо легче, чем незацикливающийся. Мой кусок кода, анализирующий несколько разных случаев, чтобы выбрать наиболее эффективный механизм перебора значений, в несколько раз длиннее оригинального фрагмента. Но самый-то простой вариант незацикливающегося FOR, пусть без разбора случаев, мог и школьник вполне сделать.
Так что, мне представляется такой вариант. Написали не думая самый простой механизм, похожий на С (тот самый корFORген
). О переполнении, о проблемах на краю диапазона, о структурности, локальности переменной и пр. никто не задумывался. Возможно даже, Вирт в этом не особо и участвовал (в первом Обероне FOR вообще не было).
Ну а сейчас это же станда-а-арт! Кривой, косой, но стандартный. Тем более, что вон в С живут же и с таким. Да и тут в большинстве случаев проблем нет, проблемы же только на краю.
Но вот тем и коварнее проблема, что вроде бы всё нормально, а вдруг...
В любом случае, FOR без переполнений, неопределенностей и зацикливаний лучше чем FOR c таковыми. Лучше во всех отношениях, не считая признания стандартом.