OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 28 Март, 2024 20:29

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




Начать новую тему Ответить на тему  [ Сообщений: 32 ]  На страницу Пред.  1, 2
Автор Сообщение
 Заголовок сообщения: Re: Опасный ASSERT
СообщениеДобавлено: Понедельник, 28 Декабрь, 2020 16:23 
Аватара пользователя

Зарегистрирован: Пятница, 11 Май, 2007 21:57
Сообщения: 1488
Откуда: Украина, Киев
Comdiv писал(а):
Это ведь пересказ обобщённого "программист не должен ошибаться".
Раз уж программист использует Oberon и COPY, он должен себе представлять их ограничения и типичное поведение


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Опасный ASSERT
СообщениеДобавлено: Понедельник, 28 Декабрь, 2020 17:42 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 1447
Откуда: Киев
Должен, должен. А ошибаться, всё-таки, не должен?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Опасный ASSERT
СообщениеДобавлено: Понедельник, 28 Декабрь, 2020 18:02 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1557
Comdiv писал(а):
Много раз писал, что авторское описание языка - это не стандарт языка. И как для авторского описания оно сделано достаточно хорошо.

Я думаю, что называть это описанием или стандартом - зависит от того, кто является владельцем. Если владельцем является Гугл или Гвидо Ван Россум, то ничего, кроме авторского описания нет и не будет. Государство или группа субъектов может взять некую версию Го или Питона и объявить, что "вот это мы будем называть американским Го или немецким Питоном или русским Обероном". Это можно озаглавить словом "стандарт" и сделать в соответствии с какими-то требованиями, внести в реестры стандартов, обязать господрядчиков следовать ему. Но это детали. Потому что и в стандарте можно через слово написать, что "поведение программы в этом случае не определено". С точки зрения соответствия правилам оформления стандартов это будет норм - иначе не было бы стандартов языка Си. По сути дела, главное - не как озаглавлен документ, а достаточно ли описание, чтобы языком было возможно пользоваться, не наступая на грабли? Естественно, есть ещё вопрос, кто виноват, если что-то пошло не так. Автор может снять с себя ответственность, а в случае стандарта наверняка кто-то крайний обязательно найдётся. Ну и там всякие вопросы правомерности применения, допустим, в атомной промышленности. Ну ок. С++ и EcmaScript стандартизированы. Можно использовать в атомной промышленности. От этого нам стало спокойнее спать?

Так вот, что мешает автору сделать это описание достаточным для практики? В случае Оберона - что мешало сделать это на протяжении 33 лет? Скромность, что ли? Тем более, если видно, что сообщество договориться не может?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Опасный ASSERT
СообщениеДобавлено: Понедельник, 28 Декабрь, 2020 18:10 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1557
Я ещё вот так скажу: соответствует ли недосказанность в описании Оберона пути Оберона? Если путь Оберона - в минимализме ради ясности, то каждое неоднозначное место в описании плодит интерпретации. 10 неоднозначностей - 1000 интерпретаций.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Опасный ASSERT
СообщениеДобавлено: Понедельник, 28 Декабрь, 2020 18:49 
Аватара пользователя

Зарегистрирован: Пятница, 11 Май, 2007 21:57
Сообщения: 1488
Откуда: Украина, Киев
budden писал(а):
Я ещё вот так скажу: соответствует ли недосказанность в описании Оберона пути Оберона?
В чём недосказанность? Про COPY всё рассказано


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Опасный ASSERT
СообщениеДобавлено: Понедельник, 28 Декабрь, 2020 23:55 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
Про КОПИ: в КомПасе его нет, зато есть селектор $ (для справки: если VAR arr: ARRAY N OF CHAR, то arr обозначает массив, а arr$ - строку, содержащуюся в этом массиве; поэтому str := arr$ означает строковое копирование).

Дано:
Код:
MODULE Files;
   TYPE Name = ARRAY 256 OF CHAR;
   PROCEDURE (dir: Directory) Old* (loc: Locator; name: Name; shared: BOOLEAN)
END Files.

И вот взгляните, делаем команду для пользовательского интерфейса:
Код:
   PROCEDURE Cmd* (IN fname: ARRAY OF CHAR);
   BEGIN ...
      f := Files.dir.Old(loc, fname$, Files.shared)
   END

Без строкового селектора $ компилятор не пропустит: ARRAY OF CHAR и Name = ARRAY N OF CHAR несовместимы. Не вопрос, поставим доллар. И легко уроним команду, передав ей 257-литерную строку. Кмк, таких удобных долларов распихано немало по ББ, и в эксплуатации, да еще если злоумышленник постарается, они обязательно взорвутся.

Что это означает? Для меня:
1) внимательность с каждым $, а также строковым +: средства мощчные, удобные, и потенциально опасные
2) Если я принимаю параметр-открытый массив, то Я отвечаю за то, чтобы заранее проверить длину строки в нем, и что она влезает туда, куда я ее захочу присвоить
3) Если я не хочу возиться с проверками вместимости, то я приму параметр-фиксированный массив. Или если это бессмысленно: например, как будет Files сообщать о недопустимой длине имени? кому? куда? Таким образом, объявляя параметр-фиксмассив, я отказываюсь отвечать за вместимость, полагаюсь на гарантии языка (макс длина фиксирована). Вдумчивый программист-клиент, читая мой интерфейс и видя в нем параметр-фиксмассив, поймет, что я передал ему ответственность за вместимость. Если он уверен, что все ок, или если авост допустим, то может ставить $.

(Для справки: $ проверяет вместимость, даже когда отключена проверка ОДЗ базовых типов. Вероятно, если отключить компиляцию ASSERTов, $ перестанет проверять; но это не точно)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Опасный ASSERT
СообщениеДобавлено: Вторник, 29 Декабрь, 2020 00:11 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
Про недоопределенность языка. Делая в Гершеле вызов процедур, и погрузившись в соглашения о вызовах, я заметил, что в КомПасе вообще НЕТ соглашения о вызовах. Т.е. даже не известно, слева направо или справа налево. Я удивился, что такая важная весчь не определена, и смутился.

Возможный вывод:
1) КомПаскаль не подходит для написания кросс-приложений: кросс-компиляторных, например, или кросс-платформенных.

Подумав еще, я нашел другой возможный вывод:
2) Поскольку в языке не определен порядок вычисления параметров, при создании переносимых программ не следует на какой-либо порядок рассчитывать. В чувствительных случаях (если есть побочные эффекты) следует порядок прописывать явно, пользуясь переменными и присваиванием.

Собсно, это подталкивает к написанию более ясных, однозначных, менее запутанных программ. Которые, кстати, можно всегда читать вправо - преимущество, не правда ли? Не нужно иногда читать влево, или какими-то зигзагами, как определения переменных в Си.

Так что казалось бы, недоопределен язык - ан нет, похоже, то, что из Сообщения убрано, сделано намеренно; по крайней мере, полезно.

***
Прим. И вот даже для справки не напишу: все-таки направо или налево вычисляются параметры? :wink:


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Опасный ASSERT
СообщениеДобавлено: Вторник, 29 Декабрь, 2020 12:30 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1557
Я думаю, это называется всё же именно "порядок вычисления аргументов", а не "соглашение о вызове". Если язык учебный, то имеет педагогический смысл нарочно наложить в него таких грабель, чтобы приучить студентов к осторожности. Если цель языка - максимальное быстродействие, то порядок вычисления аргументов нужно отдать на откуп компилятору, чтобы он мог ставить их как удобно ему. Но тогда порядок будет зависеть от флагов компилятора и может возникнуть ситуация, когда в боевом и отладочном коде аргументы вычисляются в разном порядке. Так ошибка будет прятаться от отладки. Поэтому, если цель языка - надёжность - то лучше зафиксировать порядок вычисления аргументов "слева направо" - заодно язык станет более выразительным (позволяющем более сжато выражать мысли).


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Опасный ASSERT
СообщениеДобавлено: Вторник, 29 Декабрь, 2020 13:52 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
Согласен, это про порядок вычисления, не про соглашение о вызовах. Но они связаны, не так ли: в паскале вычислялись слева направо, и в стек помещались так же; в си - наоборот.

Спорно про выразительность. Тернарный оператор тоже позволяет более сжато выражать мысли и обфусцировать их. У меня вот привычка писать текст программ плотно - в одной строке с BEGIN, DO, по нескольку (связанных смыслом) операторов. Так вот коллеги мне даже за это пеняют - говорят, слишком плотно, неясно, легко заблудиться, читая такой текст.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Опасный ASSERT
СообщениеДобавлено: Вторник, 29 Декабрь, 2020 14:51 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1557
Это не я назвал его учебным, а Сергей Дурманов вот в этом прекрасном отклике на мои рекламные тезисы:

viewtopic.php?f=61&t=6683#p113098
Цитата:
То, что безопасность была поставлена выше роли производительности это просто не правда. Оберон изначально разрабатывался как учебный язык, компилятор которого студенты могут реализовать за обозримое время.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Опасный ASSERT
СообщениеДобавлено: Вторник, 29 Декабрь, 2020 15:04 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1557
adimetrius писал(а):
по каким внутренним качествам вы бы его отнесли к "учебному"?

Мне на самом деле не важно, учебный он или нет, и я далёк от педагогики, поэтому затрудняюсь ответить. Он точно не заточен под надёжность. Отдельные реализации получились надёжными, но не видно системной работы над этим, по тем же решениям, которые "заставляют программиста быть ответственным". В то время как язык, ориентированный на надёжность, должен содержать максимальный уровень защиты от дурака и минимум неоднозначностей. Заточен ли Оберон под производительность? Утверждают, что да. Я не готов согласиться с тем, что язык со сборкой мусора может быть заточен под производительность - вообще говоря, он проигрывает по скорости языкам с явным управлением памятью. Но в этих рамках компромисс между надёжностью и производительностью остаётся на откуп разработчика компилятора. Т.е. как минимум, понятно, чем Оберон не является. А является ли он учебным - ну наверное, он ведь минималистичен и есть книжка про то, как написать его компилятор и ОС.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Опасный ASSERT
СообщениеДобавлено: Вторник, 29 Декабрь, 2020 23:12 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1557
adimetrius писал(а):
Спорно про выразительность. Тернарный оператор тоже позволяет более сжато выражать мысли и обфусцировать их.

Да, есть корреляция между плотностью текста и его непонятностью, конечно. Где-то есть золотая середина. Необязательно забиваться в вакуум. И есть случаи, когда плотность текста достигается задёшево или без потери ясности. Например, за счёт выбора коротких имён для часто встречающихся сущностей, а длинных - для редко встречающихся.

Если порядок вычислений не определён, то здесь потеря выразительности происходит почти без всякой выгоды. Т.к. даже в том случае, если аргументы функции просты, их уже нельзя сопровождать побочными эффектами. Простой вариант ошибки - человек думает, что побочных эффектов в каком-нибудь ВозьмиЧтоНибудь нет, а на самом деле там кеш и побочные эффекты есть. И в итоге человек создаёт код с неопределённым поведением, сам того не ведая.


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

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


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

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


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

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2024, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB