OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Среда, 23 Сентябрь, 2020 16:54

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




Начать новую тему Ответить на тему  [ Сообщений: 154 ]  На страницу Пред.  1, 2, 3, 4, 5, 6 ... 8  След.
Автор Сообщение
СообщениеДобавлено: Среда, 28 Январь, 2009 10:17 

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1473
Vlad писал(а):
Я и предлагаю зафиксировать - отменить нулевые ссылки.
Шило - на мыло?
Надо ещё сильно посмотреть, как изменятся алгоритмы разгребания "особых случаев"...
Вы понимаете, сколько это потянет за собой переделок и изменений даже в компиляторах? А пока с компиляторами возиться народ будет, другая его часть как-то должна в своём коде предлагаемый вами подход поддерживать... Да что там компиляторы? Например передача аргументов. Размер совокупный передаваемых данных в процедуры. Или Вы планируете обобщённо всё "через ссылки" на контексты передавать? Ага, а тем ссылкам тоже нужны свои сигнализаторы об инициализированности... Или это уже будут "особые", "системные" ссылки? :) И - т.д. ...
Цитата:
Во-первых, смотрите тему :) Во-вторых, как вы сами заметили, NIL не работает для скалярных типов.
Как естественное "выпадение" значения из множеств скалярных типов с темой связано???
Цитата:
Сущности не плодятся, вводится еще одна...
Что-то связать не удалось
Цитата:
..., совершенно ортогональная - признак "возможной неинициализированности".
Поле плавающего типа с диапазоном значений от 0 до 1 "возможности" вводить тоже потом будем?... :)
Цитата:
Вводится с конкретной целью - избежать нулевых ссылок там, где модель их не предусматривает.
Опять смысла не понял? Если модель их не предусматривает, то она это должна обеспечивать. Или - обеспечивать "ловлю" и "не допущания"... Иначе - мимо кассы...
Цитата:
Вот в обероне есть понятие типа, а есть понятие массива.
Не понятно, а почему поставлено противопоставление? Так, массивы, насколько мне известно, ТОЖЕ типы... Или - нет? :)
Цитата:
У вас не возникало желания наследовать массив? :)
Нет, у меня традиционные наклонности... :)
У меня иногда есть желание, что бы массив в Обероне был реализацией интерфейса абстрактного контейнера.
А вот иметь возможность унаследоваться или реализовать отой самый контейнер, что бы самому выглядеть аки "массив" - пуркуа бы и нет?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 28 Январь, 2009 10:44 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
Илья Ермаков писал(а):
Я не могу понять такую постановку вопроса применительно к NIL.
Какие проблемы они создают "сами по себе"? Проблемы того, что связь может быть не установлена? Ну так если она действительно может быть не установлена в предметке, что Вы предлагаете? Вводить от балды формализм, который это свойство исключит, а потом выламывать руки задаче, чтоб её под этот формализм запихать? Как при применении реляционной алгебры к задачам, выходящим за рамки по природе своей табличных?

А если всё же попытаться посмотреть, как это делается в ФП?
Вот, например, такой вариант:

Определяем тип данных Maybe x (в Хаскелле) или Option x (в Caml-семействе), у которого два варианта значений: Nothing (в Хаскелле) или None (в Caml-семействе) если у переменной пустое значение и Just x (в Хаскелле) или Some x (в Caml-семействе) если у переменной есть какое-то значение (причём это значение является валидным по определению).

Когда создаётся некий "объект" (в чистом ФП объектов вообще-то нет, есть только значения), то он принимает значения либо Nothing/None, либо Just/Some, внутри которого -- проинициализированное значение.

Затем, при обработке таких "объектов" программист обязан рассмотреть оба случая -- когда нет значения, и когда оно есть. Это предохраняет от возможных проблем, когда программа думает, что объект существует, а он на самом деле -- NULL. И бах -- Access violation!


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 28 Январь, 2009 11:17 

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1473
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();

??????????????????????????????????


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 28 Январь, 2009 12:03 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
Владимир Лось писал(а):
Пардоньте! А чем это отличается от классического

if( ptr ) ptr->DoSomething();

??????????????????????????????????

Ну хотя бы тем, что Вы не обязаны писать if( ptr ) и компилятор это никак не проверяет...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 28 Январь, 2009 13:12 

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1473
Geniepro писал(а):
Владимир Лось писал(а):
Пардоньте! А чем это отличается от классического
if( ptr ) ptr->DoSomething();
??????????????????????????????????

Ну хотя бы тем, что Вы не обязаны писать if( ptr ) и компилятор это никак не проверяет...

УРА!
Тока, знаете, там ещё и ветка else может быть... Компилятор, он что такой умный, что за меня код нужный по задаче допишет?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 28 Январь, 2009 13:29 

Зарегистрирован: Понедельник, 30 Июль, 2007 10:53
Сообщения: 1538
Откуда: Беларусь, Минск
Илья Ермаков писал(а):
Если нечто существует объективно, внешне к нашей формальной системе, то это ж очевидно ж, что любая риторика о том, что "мы избавились от этого" сведётся к вытеснению в какую-то другую форму...
В том-то и дело, что NIL нужен для того, чего объективно не существует. То есть, вводится для того, чтобы описать, что ничего нет, хотя с таким же успехом можно было вообще ничего не писать и дождаться новой инициализации. И всё!
Владимир Лось писал(а):
Опять смысла не понял? Если модель их не предусматривает, то она это должна обеспечивать. Или - обеспечивать "ловлю" и "не допущания"... Иначе - мимо кассы...

Ловлю и недопущение должны обеспечивать компиляторы (и среды исполнения, если потребуется).

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

Вот Илья возражает, что ссылки можно контролировать. В таком случае, пусть программист тогда контролирует и границы массива, и типы данных по адресу памяти. Для полноты ощущуений.

P.S. Не то, чтобы я не любил NIL... Просто размышления в слух.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 28 Январь, 2009 13:46 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
Владимир Лось писал(а):
Geniepro писал(а):
Владимир Лось писал(а):
Пардоньте! А чем это отличается от классического
if( ptr ) ptr->DoSomething();
??????????????????????????????????

Ну хотя бы тем, что Вы не обязаны писать if( ptr ) и компилятор это никак не проверяет...

УРА!
Тока, знаете, там ещё и ветка else может быть... Компилятор, он что такой умный, что за меня код нужный по задаче допишет?

Нет, он Вам по шапке даст! Потом догонит -- и ещё раз даст! :lol:

ЗЫ. Кстати, если в ФП-программе Вы напишите if-then, то компилятор заставит Вас дописать и else тоже. А иначе прямо говорите, что пользуете if-then без else, т.е. when (или unless).

А ещё, если пользоваться зависимыми типами, то, по крайней мере теоретически, можно заставить компилятор написать нужный код, реализующий спецификацию типа... http://traditio.ru/wiki/Изоморфизм_Карри-Говарда


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 28 Январь, 2009 19:18 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8368
Откуда: Троицк, Москва
Valery Solovey писал(а):
Вот Илья возражает, что ссылки можно контролировать. В таком случае, пусть программист тогда контролирует и границы массива, и типы данных по адресу памяти. Для полноты ощущуений.

Чем принципиально отличаются
i < LEN(a)
p # NIL
WITH p: Message DO
?

Проверок принадлежности области определения избежать непонятно как в общем случае.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 28 Январь, 2009 21:23 

Зарегистрирован: Понедельник, 30 Июль, 2007 10:53
Сообщения: 1538
Откуда: Беларусь, Минск
Ну не знаю. По мне, все доводы в пользу его наличия, прозвучавшие здесь, - лишь следствие пущенных корней на почве очень давних лет. Это, конечно, не должно являться призывом перейти на что-то новое, но может являться признаком, что новое как минимум не хуже.

Я так думаю, что принадлежность к области определения не обойти не только в общем случае, но даже в большинстве случаев. Но NIL - это признак того, что указатель не имеет области определения как таковой (или имеет сразу все, однако это нонсенс), а значит он делает указатель бессмысленным, пока тот содержит это значение. И смысл снова появляется после присваивания указателю нормального значения. На лицо лишнее (на первый взгляд) действие и опасность ошибки.

И вообще, указатель указывает. Указывать ни на что как-то необычно... На дорогах часто бывают пустые указатели? Белый прямоугольник с чёрной оконтовкой, и всё. : )

Если же считать NIL не отсутствием значения, а его корректным вариантом, то с семантикой становится вообще плохо: оказывается, разработана программа для получения корректного результата, всюду при присваивании используются корректные значения, и как корректный результат работы программа вылетает из-за NIL. Далеко не всякий покупатель после сообщения ему этих подробностей решится купить программу.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 28 Январь, 2009 21:52 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8368
Откуда: Троицк, Москва
Valery Solovey писал(а):
И вообще, указатель указывает. Указывать ни на что как-то необычно...
Почему же... давно и не раз замечено, что p#NIL после p := p.next играет роль ~eof после ReadInt. Может, лучше задаться вопросом, почему переменные INTEGER и т.п. не имеют значения UNDEFINED.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 28 Январь, 2009 22:46 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Илья Ермаков писал(а):
Реальный, осмысленный вариант - именно изменение семантики NIL, имхо.


Изменение на что?

Илья Ермаков писал(а):
А остальное - какая-то утопия по вытеснению неизвестно чего неизвестно куда. С моей удивлённой точки зрения.


Ладно. Я устал :) Все доводы уже были приведены.

Илья Ермаков писал(а):
Если нечто существует объективно, внешне к нашей формальной системе, то это ж очевидно ж, что любая риторика о том, что "мы избавились от этого" сведётся к вытеснению в какую-то другую форму... "Закон сохранения внешних понятий в формальной системе".


Да не в риторике, блин, дело. И не в формальности системы. Что формально изменится если компилятор перестанет проверять типы? Ничего. Работающая программа будет работать как и раньше. Неработающая скомпилится и не будет работать (обвалится в рантайме).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 28 Январь, 2009 22:50 

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2934
Откуда: г. Ярославль
Мне кажется, что ссылка (reference) на объект - вовсе не обозначение связи (которая либо может существовать, либо нет). То, что мы зовём "ссылкой", думаю, является обозначением самого объекта, а не ссылкой на него.

Отделить обозначение от содержания, по признанию самого же Хоара, оказалось очень легко ("But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement").

И получился в итоге знак, символ, который ничего не обозначает. Знак с пустым смыслом. Наверное, с точки зрения математики это представляло какой-то исследовательский интерес, но вот в реальной жизни оказалось так, как оказалось :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 28 Январь, 2009 22:52 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Владимир Лось писал(а):
Пардоньте! А чем это отличается от классического

if( ptr ) ptr->DoSomething();

??????????????????????????????????


Тем, что если вы не напишите if - компилятор даст вам по голове. Я же уже несколько раз говорил - для получения ссылки (которая всегда ненулевая) из чего-то, что "может быть не связано", требуется явно что-то написать (по аналогии с проверкой типа WITH). Неужели не очевидно, что при таком подходе ошибок, возникающих из-за нулевых ссылок будет на порядок меньше?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 28 Январь, 2009 23:00 

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1473
Vlad писал(а):
Тем, что если вы не напишите if - компилятор даст вам по голове. Я же уже несколько раз говорил - для получения ссылки (которая всегда ненулевая) из чего-то, что "может быть не связано", требуется явно что-то написать (по аналогии с проверкой типа WITH). Неужели не очевидно, что при таком подходе ошибок, возникающих из-за нулевых ссылок будет на порядок меньше?

Прочитал.
Долго думал...
Устал.
Дайте кода!
Хотя бы на некоем какбыязыке (ну, примерно на таком, если бы Вы лично решились на такой подвиг - новый язык произвесть...)
Или в нотации любого другого общепринятого, но "поправленного" Вашими идеями и желаниями на счёт ссылок...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 28 Январь, 2009 23:05 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Цитата:
Ну в C++ ссылки по определеннию ненулевые (в отличие от указателей).



Я таки дико извиняюсь что вмешиваюсь, однако в каком это месте ссылка всегда не нулевая, по кр. мере применительно к C++?

Код:
A& foo()
{
    A* p_a = NULL;
    return *p_a;
}


Компилятор по голове не бьет и вообщё всё прекрасно. ;-)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 28 Январь, 2009 23:15 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Владимир Лось писал(а):
Надо ещё сильно посмотреть, как изменятся алгоритмы разгребания "особых случаев"...


Какие такие алгоритмы?

Владимир Лось писал(а):
Вы понимаете, сколько это потянет за собой переделок и изменений даже в компиляторах?


Конкретно, например, в BB - минимум. Я уже писал - достаточно контроля за инициализированностью ссылок, плюс какое-нибудь ключевое слово для обозначения возможной "пустоты" (OPTIONAL), плюс синтаксическая конструкция для получения из "OPTIONAL Type" просто "Type" (можно использовать WITH).

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


Ой. Уж кто-кто, а Вирт со своими обронами никогда не заморачивался обратной совместимостью.

Владимир Лось писал(а):
Да что там компиляторы? Например передача аргументов. Размер совокупный передаваемых данных в процедуры. Или Вы планируете обобщённо всё "через ссылки" на контексты передавать?


Если OPTIONAL сделать только для ссылок (а не для любых скалярных типов), то с точки зрения реализации передачи аргументов - не изменится вообще ничего. Как передавались адреса, так и будут передаваться адреса. Если делать для любых типов (что ИМХО концептуально более правильно), то да, для реализации OPTIONAL скалярного типа в общем случае потребуется больше памяти (если на конкретной платформе нет какого-нибудь незадействованного лишнего бита). Но здесь все равно сохраняется принцип "вы не платите за то, что не используете" - для обычных (не-OPTIONAL) скалярных типов, все будет в точности как и раньше.

Владимир Лось писал(а):
Как естественное "выпадение" значения из множеств скалярных типов с темой связано???


Так, что если вводить концепцию "OPTIONAL" для обзначения нулевых ссылок (при том, что обычные ссылки будут всегда ненулевыми), то имеет смысл расширить эту концепцию на все типы, в том числе и скалярные.

Владимир Лось писал(а):
Если модель их не предусматривает, то она это должна обеспечивать. Или - обеспечивать "ловлю" и "не допущания"...


Ох. Ну вот покажите - как мне обеспечить ненулевую "ловлю" и "не допущания" "нулевой" БД в моей форме. В компайл-тайме.

Владимир Лось писал(а):
Не понятно, а почему поставлено противопоставление? Так, массивы, насколько мне известно, ТОЖЕ типы... Или - нет? :)


Массивы - это мета-типы, если угодно. Я бы не хотел вдаваться в терминологические споры, я уверен, что вы поняли, что я имею ввиду.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 28 Январь, 2009 23:22 

Зарегистрирован: Понедельник, 28 Ноябрь, 2005 10:28
Сообщения: 1298
Geniepro писал(а):
Затем, при обработке таких "объектов" программист обязан рассмотреть оба случая -- когда нет значения, и когда оно есть.


Кому это он обязан? И что будет, если он не рассмотрит один из случаев?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 28 Январь, 2009 23:24 

Зарегистрирован: Понедельник, 28 Ноябрь, 2005 10:28
Сообщения: 1298
Geniepro писал(а):
А ещё, если пользоваться зависимыми типами, то, по крайней мере теоретически, можно заставить компилятор написать нужный код, реализующий спецификацию типа.


Только типы при этом будут посложнее нужного кода.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 28 Январь, 2009 23:25 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Alexey Veselovsky писал(а):
Цитата:
Компилятор по голове не бьет и вообщё всё прекрасно. ;-)


Разыменование нулевого указателя - undefined behavior согласно стандарту. Так что язык не предусматривает нулевых ссылок. Получить такую ссылку на практике - да, можно, но это однозначно ошибка в программе (даже если к такой ссылке нет обращений).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 28 Январь, 2009 23:26 

Зарегистрирован: Понедельник, 28 Ноябрь, 2005 10:28
Сообщения: 1298
Valery Solovey писал(а):
И вообще, указатель указывает. Указывать ни на что как-то необычно...

Счетчик считает, множество содержит...


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

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


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

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


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

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