OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Среда, 18 Июнь, 2025 22:54

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




Начать новую тему Ответить на тему  [ Сообщений: 12 ] 
Автор Сообщение
СообщениеДобавлено: Среда, 06 Февраль, 2008 23:22 
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Известно, что охрана типа ptr(Type) даёт ошибку этапа выполнения, если ptr = NIL.

Подумалось, что лучше было бы разрешить эту операцию.
Значение NIL является совместимым со всеми типами, поэтому формально может быть приведено к любому типу.
Если дальше будет идти обращение к полю-методу ptr(Type).something - дык при селекции и ловить ошибку "NIL dereference".

Зато присваивание вида t := t.next(Type) было бы вполне корректным.
Замотало писать в полном проходе
IF t.next # NIL THEN t := t.next(Type) ELSE t := NIL END
Можно, конечно, t сделать базового типа next, и приводить в теле цикла через WITH - но всё равно лишняя конструкция...

По-моему, такое изменение семантики было бы даже полностью обратно совместимым.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 07 Февраль, 2008 01:01 
Аватара пользователя

Зарегистрирован: Суббота, 19 Ноябрь, 2005 15:59
Сообщения: 803
Откуда: Зеленоград
Тогда, вроде бы, логично распространить эту идею на операцию IS.
Но мысль о том, что выражение
Код:
(ptr IS Subtype1) & (ptr IS Subtype2) (* Subtype1 и Subtype2 -- два несовместимых подтипа *)
может оказаться "верным", мне что-то не нравится.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 07 Февраль, 2008 09:55 

Зарегистрирован: Понедельник, 28 Ноябрь, 2005 10:28
Сообщения: 1437
А почему не нравится? Это выражение верно если ptr=NIL.
Но ведь NIL можно использовать там, где ожидается значение как типа Subtype1, так и типа Subtype2.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 07 Февраль, 2008 10:03 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4625
Откуда: Россия, Орёл
Но это будет хитрый частный случай. Который не лучше ли обработать отдельным IF-ом? Тем более что для этого нововведения IF ptr # NIL THEN ... придется засовывать в реализацию охраны типа. А для всёх и всегда ли такая операция будет не лишней?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 07 Февраль, 2008 12:23 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 18:55
Сообщения: 2272
Откуда: Россия, Нижний Новгород
В C# инструкция

MyType a = (MyType)b;

присваивает переменной a значение null если b = null.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 07 Февраль, 2008 12:44 
Аватара пользователя

Зарегистрирован: Суббота, 19 Ноябрь, 2005 15:59
Сообщения: 803
Откуда: Зеленоград
Trurl писал(а):
А почему не нравится? Это выражение верно если ptr=NIL.
Я бы поостерегся считать, что ptr(Type) истинно при ptr=NIL.
Уж больно смахивает на упражнения вроде "король Франции -- лысый". :)
Как бы нам не утонуть в старых спорах между Фреге и Расселом (и это всего лишь для того, чтобы немного сократить запись?)...

см., например, Серл "Философия языка":
http://www.urss.ru/cgi-bin/db.pl?cp=&pa ... u&list=321
Цитата:
Работа [Russell 1905] открывается обсуждением проблемы предложений, содержащих определенные дескрипции, за которыми не стоит никакого объекта, то есть предложений типа The King of France is bald `Король Франции лысый'. Очевидно, что это осмысленное предложение, но в этом-то и загадка: как оно может быть осмысленным, если короля Франции не существует, и потому для выраженной в нем пропозиции нет объекта, о котором можно было бы что-то утверждать, а следовательно, в нем нет ничего, по отношению к чему предикат мог бы быть истинным или ложным? Как может иметь смысл такое предложение, если очевидно, что пропозиция, которую оно выражает, не является ни истинной, ни ложной? Ответ Фреге на этот вопрос был таким: предложение может быть осмысленным даже при том, что его субъектное выражение не имеет референции. По Фреге предложение может не иметь истинностного значения, но отсутствие истинностного значения не лишает предложения смысла и не превращает его в бессмыслицу. И если кто-то ошибочно считает, что предложение становится бессмысленным, то он просто путает смысл с референцией. Рассел, уже отвергнувший теорию Фреге о смысле и референции, дает, однако, совсем другой ответ на тот же вопрос: лишь на первый взгляд кажется, что данное предложение имеет субъектно-предикатную логическую форму, а на самом деле это не так. Грамматическая форма предложения здесь затушевывает его логическую форму, делая ее непрозрачной. В действительности же логическая форма этого предложения представляет собой конъюнкцию утверждений, одним из которых является утверждение существования. Иными словами, Рассел предлагает следующий анализ для предложения The King of France is bald `Король Франции лысый':

There is a King of France `Существует король Франции'.

There is not more than one King of France `Существует не более одного короля Франции'.

Whatever is King of France he is bald `Каков бы ни был король Франции, он лысый'.

При такой интерпретации легко видеть, что анализируемое предложение является осмысленным, а выраженная в нем пропозиция ложна. Она ложна потому, что короля Франции не существует.


Последний раз редактировалось AVC Четверг, 07 Февраль, 2008 13:22, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 07 Февраль, 2008 13:18 

Зарегистрирован: Понедельник, 28 Ноябрь, 2005 10:28
Сообщения: 1437
Как-то же надо обосновывать возможность присваивания
Код:
ptr := NIL


Цитата:
- У вас газировка есть?
- Да, с малиновым сиропом и с вишневым.
- Мне, пожалуйста, без сиропа.
- А Вам без какого, без малинового или без вишневого?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 07 Февраль, 2008 21:59 

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1693
Trurl писал(а):
Как-то же надо обосновывать возможность присваивания
Код:
ptr := NIL


Надо подумать...

С одной стороны, NIL принадлежит любому множеству любых типов указателей (на любые типы).

С другой - как-либо его "проверять" на принадлежность типу мы не можем: никакой информации о статическом и о динамическом типе "пустого" элемента мы не можем в принципе получить...

Наверное, первая "сторона" главенствует...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 08 Февраль, 2008 11:26 

Зарегистрирован: Понедельник, 30 Июль, 2007 10:53
Сообщения: 1538
Откуда: Беларусь, Минск
Когда я учился в университете, то в те времена определения указателя давалось нам как сущность, указывающая либо на адрес в памяти, либо никуда не указывающая (указывающая в никуда).

С указателями на объекты, как мне кажется, то же самое - либо указываем на адрес объекта либо никуда не указываем.

NIL не объект, а адрес. И это становится существенным при объявлении объекта в динамической и статической памяти.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 08 Февраль, 2008 13:53 
Аватара пользователя

Зарегистрирован: Среда, 22 Август, 2007 04:30
Сообщения: 20
Откуда: Новокузнецк, Кемеровская область
Владимир Лось писал(а):
С одной стороны, NIL принадлежит любому множеству любых типов указателей (на любые типы).

Может быть это все-таки неправильно, что NIL неявно принадлежит всем типам? Не нарушает ли это строгую типизацию?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 08 Февраль, 2008 23:52 

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1693
Юра писал(а):
Владимир Лось писал(а):
С одной стороны, NIL принадлежит любому множеству любых типов указателей (на любые типы).

Может быть это все-таки неправильно, что NIL неявно принадлежит всем типам? Не нарушает ли это строгую типизацию?

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

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

WHEN p IS type DO ... END

Но потом приходит к выводу, что это не слишком рационально и, в конце концов, приводит к усложнению архитектурных решений и запутанной логике (в масштабах проектируемой системы). Он останавливается на "разделении ролей": для проверки действенности указателя - проверять его на NIL в IF, а для приведения и охраны - WITH (с абортом)... (Кстати. за десяток лет до Оберона, в Эль-76, действовоал тот же принцип)...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 09 Февраль, 2008 23:10 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 18:55
Сообщения: 2272
Откуда: Россия, Нижний Новгород
Владимир Лось писал(а):
Он останавливается на "разделении ролей"

Чтобы инструменты были "ортогональные"...


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 12 ] 

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


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

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


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

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