OberonCore

Шило - на мыло?
Надо ещё сильно посмотреть, как изменятся алгоритмы разгребания "особых случаев"...
Вы понимаете, сколько это потянет за собой переделок и изменений даже в компиляторах? А пока с компиляторами возиться народ будет, другая его часть как-то должна в своём коде предлагаемый вами подход поддерживать... Да что там компиляторы? Например передача аргументов. Размер совокупный передаваемых данных в процедуры. Или Вы планируете обобщённо всё "через ссылки" на контексты передавать? Ага, а тем ссылкам тоже нужны свои сигнализаторы об инициализированности... Или это уже будут "особые", "системные" ссылки? И - т.д. ...
Как естественное "выпадение" значения из множеств скалярных типов с темой связано???
Что-то связать не удалось
Поле плавающего типа с диапазоном значений от 0 до 1 "возможности" вводить тоже потом будем?...
Опять смысла не понял? Если модель их не предусматривает, то она это должна обеспечивать. Или - обеспечивать "ловлю" и "не допущания"... Иначе - мимо кассы...
Не понятно, а почему поставлено противопоставление? Так, массивы, насколько мне известно, ТОЖЕ типы... Или - нет?
Нет, у меня традиционные наклонности...
У меня иногда есть желание, что бы массив в Обероне был реализацией интерфейса абстрактного контейнера.
А вот иметь возможность унаследоваться или реализовать отой самый контейнер, что бы самому выглядеть аки "массив" - пуркуа бы и нет?

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

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

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

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

Пардоньте! А чем это отличается от классического

if( ptr ) ptr->DoSomething();

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

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

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

В том-то и дело, что NIL нужен для того, чего объективно не существует. То есть, вводится для того, чтобы описать, что ничего нет, хотя с таким же успехом можно было вообще ничего не писать и дождаться новой инициализации. И всё!

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

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

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

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

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

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

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

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

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

Ну не знаю. По мне, все доводы в пользу его наличия, прозвучавшие здесь, - лишь следствие пущенных корней на почве очень давних лет. Это, конечно, не должно являться призывом перейти на что-то новое, но может являться признаком, что новое как минимум не хуже.

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

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

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

Почему же... давно и не раз замечено, что p#NIL после p := p.next играет роль ~eof после ReadInt. Может, лучше задаться вопросом, почему переменные INTEGER и т.п. не имеют значения UNDEFINED.

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



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



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

Мне кажется, что ссылка (reference) на объект - вовсе не обозначение связи (которая либо может существовать, либо нет). То, что мы зовём "ссылкой", думаю, является обозначением самого объекта, а не ссылкой на него.

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

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

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

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

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



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

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



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



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



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



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



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



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

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

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

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

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