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

Твердыня модульных языков
Текущее время: 29 мар 2024, 00:47

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




Начать новую тему Ответить на тему  [ Сообщений: 33 ]  На страницу Пред.  1, 2, 3, 4
Автор Сообщение
 Заголовок сообщения: Re: FOR в Обероне 7. Стало только хуже
СообщениеДобавлено: 09 июн 2019, 18:38 
Не в сети

Сообщения: 146
Saferoll писал(а):
Zorko сообщил мне, что он со товарищи (за что ему и им всем спасибо!) заглянул в виртовский компилятор

Я уже писал об это в канале OberonCore, где было это обсуждение. Вот некоторые сообщения оттуда

Цитата:
Vlad, [07.06.19 22:21]
Толку подгонять трактовку "чего хотел сказать Вирт" под свое понимание правильного FOR, если потом окажется, что он сам реализовал FOR вот так вот.

Константин, [08.06.19 00:03]
[В ответ на Vlad]
Для неопределённого поведения не существует единственного воплощения, поэтому образцы в этом отношении ничего не показывают. Неопределённость можно воплотить и наиболее простым способом, и наиболее ошибкоустойчивым. А так - всё равно, что писать трансляторы Си с оглядкой на воплощение Денниса Ритчи. Вот gcc и clang по разному воплощают не определённое в стандарте поведение не только относительно друг друга, но и относительно себя в зависимости от опций компилятора.

Vlad, [08.06.19 01:01]
Неопределенное поведение (undefined behavior) применительно к сям это совсем из другой оперы нежели "неописанное поведение" в случае обероновского репорта.

Vlad, [08.06.19 01:03]
UB специально описывают, чтобы:
1. программист про него знал
2. компилтяторописатель мог генерить наиболее эффектвный код для целевой платформы

Vlad, [08.06.19 01:04]
Но у оберонщиков почему-то представление, что сишные UB исключительно для того, чтобы багов было больше...

Константин, [08.06.19 10:51]
[В ответ на Vlad]
Вы просто не знакомы ни с понятием неопределённого поведения, ни с его определением в стандарте Си:
3.4.3 undefined behavior - behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which this International Standard imposes no requirements
Явная пометка словами неопределённого поведения - это + к понятности, и это хорошо, но этого не требуется, для того, чтобы поведение было неопределённым и стандарт не утверждает, что все места НП помечены как НП.
Также, утверждение, что НП описывают для того, чтобы можно было генерировать наиболее эффективный код - это миф.
NOTE Possible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message)
Прямо в стандарте указано, что одной из воможных реакций на достижение НП является остановка и диагностика, включая время трансляции. Естественно, диагностику времени исполнения трудно сделать, не потеряв в эффективности. Примечательно то, что современные компиляторы достаточно давно умеют делать нужные проверки, обеспечивая более высокую ошибкоуствочивость, но проблема в том, что пользователям это трудно объяснить, потому что они верят в мифы о том, что "это для высокой эффективности".
Соответственно, и Ваше приписывание группе людей мнения об UB - это такие же фантазии в Вашей голове, как и у Олега про правоверность и т.п.

Vlad, [08.06.19 16:46]
[В ответ на Константин]
Спасибо за более развернутое пояснение с цитатами. В каком именно месте оно противоречит моим очень кратким тезисам?

Константин, [08.06.19 16:55]
Во всём. Что добавить? Лучше процитировать ещё кусок специально для Вас:
Undefined behavior is otherwise indicated in this International Standard by the words ‘‘undefined behavior’’ or by the omission of any explicit definition of behavior.

Oleg N. Cher, [08.06.19 17:03]
Влад, мы все сильно тупые, чтобы понять, что имеет в виду Константин. Забей

Vlad, [08.06.19 17:30]
[В ответ на Константин]
Слово "omission" противоречит? Хорошо, был неправ - недописанности в оберон репорте можно формально трактовать как UB. Но сути не меняет - в сишном стандарте стараются явно описать все UB.

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


Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: FOR в Обероне 7. Стало только хуже
СообщениеДобавлено: 09 июн 2019, 18:44 
Не в сети
Аватара пользователя

Сообщения: 1019
Откуда: Днепропетровская обл.
Раз Вы уже это сюда притащили, то может поясните, какое отношение всё это имеет к FOR в Обероне-07? Давайте, Константин, для большей ясности Вы нам скажете: Вы считаете, что сообщение о языке несёт какую-то неопределённость в его описании? Разрешает вольную трактовку понятия "конечное значение вычисляется/не вычисляется в каждой итерации цикла" - понимайте и реализуйте как кому хочется.


Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: FOR в Обероне 7. Стало только хуже
СообщениеДобавлено: 09 июн 2019, 22:07 
Не в сети
Администратор
Аватара пользователя

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

_________________
А кроме того, я думаю, что корFORген должен быть разрушен!


Вернуться к началу
 Профиль  
Ответить с цитатой  
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 33 ]  На страницу Пред.  1, 2, 3, 4

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


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

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


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

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