OberonCore https://forum.oberoncore.ru/ |
|
Хоар: "Нулевые ссылки -- ошибка стоимостью в миллиард доллар https://forum.oberoncore.ru/viewtopic.php?f=27&t=1320 |
Страница 3 из 8 |
Автор: | Wlad [ Среда, 28 Январь, 2009 10:17 ] |
Заголовок сообщения: | Re: Хоар: "Нулевые ссылки -- ошибка стоимостью в миллиард доллар |
Vlad писал(а): Я и предлагаю зафиксировать - отменить нулевые ссылки. Шило - на мыло?Надо ещё сильно посмотреть, как изменятся алгоритмы разгребания "особых случаев"... Вы понимаете, сколько это потянет за собой переделок и изменений даже в компиляторах? А пока с компиляторами возиться народ будет, другая его часть как-то должна в своём коде предлагаемый вами подход поддерживать... Да что там компиляторы? Например передача аргументов. Размер совокупный передаваемых данных в процедуры. Или Вы планируете обобщённо всё "через ссылки" на контексты передавать? Ага, а тем ссылкам тоже нужны свои сигнализаторы об инициализированности... Или это уже будут "особые", "системные" ссылки? И - т.д. ... Цитата: Во-первых, смотрите тему Во-вторых, как вы сами заметили, NIL не работает для скалярных типов. Как естественное "выпадение" значения из множеств скалярных типов с темой связано??? Цитата: Сущности не плодятся, вводится еще одна... Что-то связать не удалосьЦитата: ..., совершенно ортогональная - признак "возможной неинициализированности". Поле плавающего типа с диапазоном значений от 0 до 1 "возможности" вводить тоже потом будем?... Цитата: Вводится с конкретной целью - избежать нулевых ссылок там, где модель их не предусматривает. Опять смысла не понял? Если модель их не предусматривает, то она это должна обеспечивать. Или - обеспечивать "ловлю" и "не допущания"... Иначе - мимо кассы...Цитата: Вот в обероне есть понятие типа, а есть понятие массива. Не понятно, а почему поставлено противопоставление? Так, массивы, насколько мне известно, ТОЖЕ типы... Или - нет? Цитата: У вас не возникало желания наследовать массив? Нет, у меня традиционные наклонности... У меня иногда есть желание, что бы массив в Обероне был реализацией интерфейса абстрактного контейнера. А вот иметь возможность унаследоваться или реализовать отой самый контейнер, что бы самому выглядеть аки "массив" - пуркуа бы и нет? |
Автор: | Geniepro [ Среда, 28 Январь, 2009 10:44 ] |
Заголовок сообщения: | Re: Хоар: "Нулевые ссылки -- ошибка стоимостью в миллиард доллар |
Илья Ермаков писал(а): Я не могу понять такую постановку вопроса применительно к NIL. Какие проблемы они создают "сами по себе"? Проблемы того, что связь может быть не установлена? Ну так если она действительно может быть не установлена в предметке, что Вы предлагаете? Вводить от балды формализм, который это свойство исключит, а потом выламывать руки задаче, чтоб её под этот формализм запихать? Как при применении реляционной алгебры к задачам, выходящим за рамки по природе своей табличных? А если всё же попытаться посмотреть, как это делается в ФП? Вот, например, такой вариант: Определяем тип данных Maybe x (в Хаскелле) или Option x (в Caml-семействе), у которого два варианта значений: Nothing (в Хаскелле) или None (в Caml-семействе) если у переменной пустое значение и Just x (в Хаскелле) или Some x (в Caml-семействе) если у переменной есть какое-то значение (причём это значение является валидным по определению). Когда создаётся некий "объект" (в чистом ФП объектов вообще-то нет, есть только значения), то он принимает значения либо Nothing/None, либо Just/Some, внутри которого -- проинициализированное значение. Затем, при обработке таких "объектов" программист обязан рассмотреть оба случая -- когда нет значения, и когда оно есть. Это предохраняет от возможных проблем, когда программа думает, что объект существует, а он на самом деле -- NULL. И бах -- Access violation! |
Автор: | Wlad [ Среда, 28 Январь, 2009 11:17 ] |
Заголовок сообщения: | Re: Хоар: "Нулевые ссылки -- ошибка стоимостью в миллиард доллар |
Geniepro писал(а): Илья Ермаков писал(а): Определяем тип данных Maybe x (в Хаскелле) или Option x (в Caml-семействе), у которого два варианта значений: Nothing (в Хаскелле) или None (в Caml-семействе) если у переменной пустое значение и Just x (в Хаскелле) или Some x (в Caml-семействе) если у переменной есть какое-то значение (причём это значение является валидным по определению). Когда создаётся некий "объект" (в чистом ФП объектов вообще-то нет, есть только значения), то он принимает значения либо Nothing/None, либо Just/Some, внутри которого -- проинициализированное значение. Затем, при обработке таких "объектов" программист обязан рассмотреть оба случая -- когда нет значения, и когда оно есть. Это предохраняет от возможных проблем, когда программа думает, что объект существует, а он на самом деле -- NULL. И бах -- Access violation! Пардоньте! А чем это отличается от классического if( ptr ) ptr->DoSomething(); ?????????????????????????????????? |
Автор: | Geniepro [ Среда, 28 Январь, 2009 12:03 ] |
Заголовок сообщения: | Re: Хоар: "Нулевые ссылки -- ошибка стоимостью в миллиард доллар |
Владимир Лось писал(а): Пардоньте! А чем это отличается от классического if( ptr ) ptr->DoSomething(); ?????????????????????????????????? Ну хотя бы тем, что Вы не обязаны писать if( ptr ) и компилятор это никак не проверяет... |
Автор: | Wlad [ Среда, 28 Январь, 2009 13:12 ] |
Заголовок сообщения: | Re: Хоар: "Нулевые ссылки -- ошибка стоимостью в миллиард доллар |
Geniepro писал(а): Владимир Лось писал(а): Пардоньте! А чем это отличается от классического if( ptr ) ptr->DoSomething(); ?????????????????????????????????? Ну хотя бы тем, что Вы не обязаны писать if( ptr ) и компилятор это никак не проверяет... УРА! Тока, знаете, там ещё и ветка else может быть... Компилятор, он что такой умный, что за меня код нужный по задаче допишет? |
Автор: | Valery Solovey [ Среда, 28 Январь, 2009 13:29 ] |
Заголовок сообщения: | Re: Хоар: "Нулевые ссылки -- ошибка стоимостью в миллиард доллар |
Илья Ермаков писал(а): Если нечто существует объективно, внешне к нашей формальной системе, то это ж очевидно ж, что любая риторика о том, что "мы избавились от этого" сведётся к вытеснению в какую-то другую форму... В том-то и дело, что NIL нужен для того, чего объективно не существует. То есть, вводится для того, чтобы описать, что ничего нет, хотя с таким же успехом можно было вообще ничего не писать и дождаться новой инициализации. И всё!Владимир Лось писал(а): Опять смысла не понял? Если модель их не предусматривает, то она это должна обеспечивать. Или - обеспечивать "ловлю" и "не допущания"... Иначе - мимо кассы... Ловлю и недопущение должны обеспечивать компиляторы (и среды исполнения, если потребуется). Но есть проблемы. Если в конструкции CASE не выполняется одно из явно заданных условий, то получаем трап. Чтобы этого избежать появился пункт ELSE (на всякий случай). То же самое можно применить и к ссылкам. На всякий случай есть NIL. Но в большинстве случаев можно обходиться и без него. Возникает вопрос - можно ли как-то изменить язык (не особо теряя в эффективности), чтобы исключить такие случаи и исключить NIL вовсе, потому что его можно трактовать как узаконенную ошибку в программе. Вот Илья возражает, что ссылки можно контролировать. В таком случае, пусть программист тогда контролирует и границы массива, и типы данных по адресу памяти. Для полноты ощущуений. P.S. Не то, чтобы я не любил NIL... Просто размышления в слух. |
Автор: | Geniepro [ Среда, 28 Январь, 2009 13:46 ] |
Заголовок сообщения: | Re: Хоар: "Нулевые ссылки -- ошибка стоимостью в миллиард доллар |
Владимир Лось писал(а): Geniepro писал(а): Владимир Лось писал(а): Пардоньте! А чем это отличается от классического if( ptr ) ptr->DoSomething(); ?????????????????????????????????? Ну хотя бы тем, что Вы не обязаны писать if( ptr ) и компилятор это никак не проверяет... УРА! Тока, знаете, там ещё и ветка else может быть... Компилятор, он что такой умный, что за меня код нужный по задаче допишет? Нет, он Вам по шапке даст! Потом догонит -- и ещё раз даст! ЗЫ. Кстати, если в ФП-программе Вы напишите if-then, то компилятор заставит Вас дописать и else тоже. А иначе прямо говорите, что пользуете if-then без else, т.е. when (или unless). А ещё, если пользоваться зависимыми типами, то, по крайней мере теоретически, можно заставить компилятор написать нужный код, реализующий спецификацию типа... http://traditio.ru/wiki/Изоморфизм_Карри-Говарда |
Автор: | Info21 [ Среда, 28 Январь, 2009 19:18 ] |
Заголовок сообщения: | Re: Хоар: "Нулевые ссылки -- ошибка стоимостью в миллиард доллар |
Valery Solovey писал(а): Вот Илья возражает, что ссылки можно контролировать. В таком случае, пусть программист тогда контролирует и границы массива, и типы данных по адресу памяти. Для полноты ощущуений. Чем принципиально отличаются i < LEN(a) p # NIL WITH p: Message DO ? Проверок принадлежности области определения избежать непонятно как в общем случае. |
Автор: | Valery Solovey [ Среда, 28 Январь, 2009 21:23 ] |
Заголовок сообщения: | Re: Хоар: "Нулевые ссылки -- ошибка стоимостью в миллиард доллар |
Ну не знаю. По мне, все доводы в пользу его наличия, прозвучавшие здесь, - лишь следствие пущенных корней на почве очень давних лет. Это, конечно, не должно являться призывом перейти на что-то новое, но может являться признаком, что новое как минимум не хуже. Я так думаю, что принадлежность к области определения не обойти не только в общем случае, но даже в большинстве случаев. Но NIL - это признак того, что указатель не имеет области определения как таковой (или имеет сразу все, однако это нонсенс), а значит он делает указатель бессмысленным, пока тот содержит это значение. И смысл снова появляется после присваивания указателю нормального значения. На лицо лишнее (на первый взгляд) действие и опасность ошибки. И вообще, указатель указывает. Указывать ни на что как-то необычно... На дорогах часто бывают пустые указатели? Белый прямоугольник с чёрной оконтовкой, и всё. : ) Если же считать NIL не отсутствием значения, а его корректным вариантом, то с семантикой становится вообще плохо: оказывается, разработана программа для получения корректного результата, всюду при присваивании используются корректные значения, и как корректный результат работы программа вылетает из-за NIL. Далеко не всякий покупатель после сообщения ему этих подробностей решится купить программу. |
Автор: | Info21 [ Среда, 28 Январь, 2009 21:52 ] |
Заголовок сообщения: | Re: Хоар: "Нулевые ссылки -- ошибка стоимостью в миллиард доллар |
Valery Solovey писал(а): И вообще, указатель указывает. Указывать ни на что как-то необычно... Почему же... давно и не раз замечено, что p#NIL после p := p.next играет роль ~eof после ReadInt. Может, лучше задаться вопросом, почему переменные INTEGER и т.п. не имеют значения UNDEFINED.
|
Автор: | Vlad [ Среда, 28 Январь, 2009 22:46 ] |
Заголовок сообщения: | Re: Хоар: "Нулевые ссылки -- ошибка стоимостью в миллиард доллар |
Илья Ермаков писал(а): Реальный, осмысленный вариант - именно изменение семантики NIL, имхо. Изменение на что? Илья Ермаков писал(а): А остальное - какая-то утопия по вытеснению неизвестно чего неизвестно куда. С моей удивлённой точки зрения. Ладно. Я устал Все доводы уже были приведены. Илья Ермаков писал(а): Если нечто существует объективно, внешне к нашей формальной системе, то это ж очевидно ж, что любая риторика о том, что "мы избавились от этого" сведётся к вытеснению в какую-то другую форму... "Закон сохранения внешних понятий в формальной системе". Да не в риторике, блин, дело. И не в формальности системы. Что формально изменится если компилятор перестанет проверять типы? Ничего. Работающая программа будет работать как и раньше. Неработающая скомпилится и не будет работать (обвалится в рантайме). |
Автор: | Иван Кузьмицкий [ Среда, 28 Январь, 2009 22:50 ] |
Заголовок сообщения: | Re: Хоар: "Нулевые ссылки -- ошибка стоимостью в миллиард доллар |
Мне кажется, что ссылка (reference) на объект - вовсе не обозначение связи (которая либо может существовать, либо нет). То, что мы зовём "ссылкой", думаю, является обозначением самого объекта, а не ссылкой на него. Отделить обозначение от содержания, по признанию самого же Хоара, оказалось очень легко ("But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement"). И получился в итоге знак, символ, который ничего не обозначает. Знак с пустым смыслом. Наверное, с точки зрения математики это представляло какой-то исследовательский интерес, но вот в реальной жизни оказалось так, как оказалось |
Автор: | Vlad [ Среда, 28 Январь, 2009 22:52 ] |
Заголовок сообщения: | Re: Хоар: "Нулевые ссылки -- ошибка стоимостью в миллиард доллар |
Владимир Лось писал(а): Пардоньте! А чем это отличается от классического if( ptr ) ptr->DoSomething(); ?????????????????????????????????? Тем, что если вы не напишите if - компилятор даст вам по голове. Я же уже несколько раз говорил - для получения ссылки (которая всегда ненулевая) из чего-то, что "может быть не связано", требуется явно что-то написать (по аналогии с проверкой типа WITH). Неужели не очевидно, что при таком подходе ошибок, возникающих из-за нулевых ссылок будет на порядок меньше? |
Автор: | Wlad [ Среда, 28 Январь, 2009 23:00 ] |
Заголовок сообщения: | Re: Хоар: "Нулевые ссылки -- ошибка стоимостью в миллиард доллар |
Vlad писал(а): Тем, что если вы не напишите if - компилятор даст вам по голове. Я же уже несколько раз говорил - для получения ссылки (которая всегда ненулевая) из чего-то, что "может быть не связано", требуется явно что-то написать (по аналогии с проверкой типа WITH). Неужели не очевидно, что при таком подходе ошибок, возникающих из-за нулевых ссылок будет на порядок меньше? Прочитал. Долго думал... Устал. Дайте кода! Хотя бы на некоем какбыязыке (ну, примерно на таком, если бы Вы лично решились на такой подвиг - новый язык произвесть...) Или в нотации любого другого общепринятого, но "поправленного" Вашими идеями и желаниями на счёт ссылок... |
Автор: | Alexey Veselovsky [ Среда, 28 Январь, 2009 23:05 ] |
Заголовок сообщения: | Re: Хоар: "Нулевые ссылки -- ошибка стоимостью в миллиард доллар |
Цитата: Ну в C++ ссылки по определеннию ненулевые (в отличие от указателей). Я таки дико извиняюсь что вмешиваюсь, однако в каком это месте ссылка всегда не нулевая, по кр. мере применительно к C++? Код: A& foo() { A* p_a = NULL; return *p_a; } Компилятор по голове не бьет и вообщё всё прекрасно. |
Автор: | Vlad [ Среда, 28 Январь, 2009 23:15 ] |
Заголовок сообщения: | Re: Хоар: "Нулевые ссылки -- ошибка стоимостью в миллиард доллар |
Владимир Лось писал(а): Надо ещё сильно посмотреть, как изменятся алгоритмы разгребания "особых случаев"... Какие такие алгоритмы? Владимир Лось писал(а): Вы понимаете, сколько это потянет за собой переделок и изменений даже в компиляторах? Конкретно, например, в BB - минимум. Я уже писал - достаточно контроля за инициализированностью ссылок, плюс какое-нибудь ключевое слово для обозначения возможной "пустоты" (OPTIONAL), плюс синтаксическая конструкция для получения из "OPTIONAL Type" просто "Type" (можно использовать WITH). Владимир Лось писал(а): А пока с компиляторами возиться народ будет, другая его часть как-то должна в своём коде предлагаемый вами подход поддерживать... Ой. Уж кто-кто, а Вирт со своими обронами никогда не заморачивался обратной совместимостью. Владимир Лось писал(а): Да что там компиляторы? Например передача аргументов. Размер совокупный передаваемых данных в процедуры. Или Вы планируете обобщённо всё "через ссылки" на контексты передавать? Если OPTIONAL сделать только для ссылок (а не для любых скалярных типов), то с точки зрения реализации передачи аргументов - не изменится вообще ничего. Как передавались адреса, так и будут передаваться адреса. Если делать для любых типов (что ИМХО концептуально более правильно), то да, для реализации OPTIONAL скалярного типа в общем случае потребуется больше памяти (если на конкретной платформе нет какого-нибудь незадействованного лишнего бита). Но здесь все равно сохраняется принцип "вы не платите за то, что не используете" - для обычных (не-OPTIONAL) скалярных типов, все будет в точности как и раньше. Владимир Лось писал(а): Как естественное "выпадение" значения из множеств скалярных типов с темой связано??? Так, что если вводить концепцию "OPTIONAL" для обзначения нулевых ссылок (при том, что обычные ссылки будут всегда ненулевыми), то имеет смысл расширить эту концепцию на все типы, в том числе и скалярные. Владимир Лось писал(а): Если модель их не предусматривает, то она это должна обеспечивать. Или - обеспечивать "ловлю" и "не допущания"... Ох. Ну вот покажите - как мне обеспечить ненулевую "ловлю" и "не допущания" "нулевой" БД в моей форме. В компайл-тайме. Владимир Лось писал(а): Не понятно, а почему поставлено противопоставление? Так, массивы, насколько мне известно, ТОЖЕ типы... Или - нет? Массивы - это мета-типы, если угодно. Я бы не хотел вдаваться в терминологические споры, я уверен, что вы поняли, что я имею ввиду. |
Автор: | Trurl [ Среда, 28 Январь, 2009 23:22 ] |
Заголовок сообщения: | Re: Хоар: "Нулевые ссылки -- ошибка стоимостью в миллиард доллар |
Geniepro писал(а): Затем, при обработке таких "объектов" программист обязан рассмотреть оба случая -- когда нет значения, и когда оно есть. Кому это он обязан? И что будет, если он не рассмотрит один из случаев? |
Автор: | Trurl [ Среда, 28 Январь, 2009 23:24 ] |
Заголовок сообщения: | Re: Хоар: "Нулевые ссылки -- ошибка стоимостью в миллиард доллар |
Geniepro писал(а): А ещё, если пользоваться зависимыми типами, то, по крайней мере теоретически, можно заставить компилятор написать нужный код, реализующий спецификацию типа. Только типы при этом будут посложнее нужного кода. |
Автор: | Vlad [ Среда, 28 Январь, 2009 23:25 ] |
Заголовок сообщения: | Re: Хоар: "Нулевые ссылки -- ошибка стоимостью в миллиард доллар |
Alexey Veselovsky писал(а): Цитата: Компилятор по голове не бьет и вообщё всё прекрасно. Разыменование нулевого указателя - undefined behavior согласно стандарту. Так что язык не предусматривает нулевых ссылок. Получить такую ссылку на практике - да, можно, но это однозначно ошибка в программе (даже если к такой ссылке нет обращений). |
Автор: | Trurl [ Среда, 28 Январь, 2009 23:26 ] |
Заголовок сообщения: | Re: Хоар: "Нулевые ссылки -- ошибка стоимостью в миллиард доллар |
Valery Solovey писал(а): И вообще, указатель указывает. Указывать ни на что как-то необычно... Счетчик считает, множество содержит... |
Страница 3 из 8 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |