Ответ на »сообщение 4500« (captain cobalt)
___________________________
Как известно,
Кому и из каких источников известно? :о)
Для доп. уровня солидности ещё лучше было начать фразу так: "Любой, хоть мало-мальски вменяемый человек понимает, что ..." или "Все профессиональные программисты знают, что...". Запишите на будущее... :о)

в Active Oberon специально введён абстрактный тип OBJECT; который является подразумеваемым базовым типом для всех других OBJECT.
Ну, положим, конкретно в АО OBJECT был введён базовым для всех просто из-за чисто утилитарных соображений со стороны сборщика мусора (как разновидность типов, с которыми он работает) + поддержка активностей.

Это указатель на произвольный тип.
Ой, капитан, вы меня пугаете!... :о)
Говоря строго, тип OBJECT – НЕ указатель. И он - совсем НЕ указатель на ПРОИЗВОЛЬНЫЙ тип...

Но с самим объектом можно что-нибудь сделать только проверив тип.
Вы меня пугаете ещё больше! Это шо ж, вы все аргументы-объекты в функциях (процедурах) объявляете как OBJECT, а потом, после приведения/проверки, начинаете им пользоваться? :о)

Это тоже "ненужная" и "вредная" вещь?
Вы знаете, я что-то начинают терять убеждённость в необходимости дальнейшего обсуждения...

Ответ на »сообщение 4499« (Владимир Лось)
___________________________
Указатели всегда указывают на один и тот же тип. В ООП-мире – на тип, который описан в описании типа данного указателя. Уже интерпретация, "выгребание" нужной "точки зрения" на данный объект – обеспечивается механизмами обеспечения полиморфизма конкретного языка.
...
Что касается Оберона (конкретно – Активного), то я до сих пор слабо представляю, что это такое и зачем оно нужно в этом языке?...

Это странно и удивительно.

Как известно, в Active Oberon специально введён абстрактный тип OBJECT; который является подразумеваемым базовым типом для всех других OBJECT. Это указатель на произвольный тип. Но с самим объектом можно что-нибудь сделать только проверив тип.

Это тоже "ненужная" и "вредная" вещь?

Ответ на »сообщение 4498« (captain cobalt)
___________________________
Действительно, в каждый фиксированный момент времени ячейка памяти может содержать данные одного типа. Но это не значит что всю её жизнь это должен быть один тип.
Если вы про языки с динамическим изменением типа переменной во время выполнения программы, то задумайтесь, помышляете ли вы об одних и тех же сущностях предметной области в таком случае?...
Причём, не путайте это с понятиями статического и динамического типа. Статический тип – это "навсегда", на всё время существования сущности, а уж трактовка "угла зрения", "аспекта", "предоставляемого интерфейса", "динамического типа" – это всё как раз то, что я имел в виду, зависит от множества поддерживаемых интерфейсов данным объектом... В подавляющем большинстве случаев дополнительно налагают требования наличия "родства" динамических типов статическому...

Или указатели. В один момент времени указатель может указывать на переменную одного типа, а в следующий момент времени на переменную другого типа. И обрабатываться одним куском кода.
Указатели всегда указывают на один и тот же тип. В ООП-мире – на тип, который описан в описании типа данного указателя. Уже интерпретация, "выгребание" нужной "точки зрения" на данный объект – обеспечивается механизмами обеспечения полиморфизма конкретного языка.

class Parent_t { ... };
class Child_t: public Parent_t { ... };
Parent_t* parent_ptr;

parent_ptr ВСЕГДА указывает на объекты типа Parent_t. И операции-методы того, на что указывает parent_ptr подразумеваются типа Parent_t. Это просто свойство конкретно Си++, что в нём разрешена поддержка напрямую (через присвоения указателей на детей к указателям на предков + таблицы виртуальных методов) дерева классификации. То есть "по-хорошему" это - просто "трюк" конкретного языка, в связи с тем, что решили отказаться от конструкции parent_ptr as Child_t и проверки выполнимости приведения к конкретному интерфейсу... Там есть  static_cast & dynamic_cast, но их семантика так и осталась где-то очень далеко от прямой поддержки понятия "интерфейс"...

А ещё бывают преобразования типа. Для скалярных типов они обычно встроены в язык программирования.
Тип самой "преобразуемой" скалярной переменной при этом НЕ МЕНЯЕТСЯ. По сути дела в этих выражениях вы вызываете ФУНКЦИЮ преобразования (на входе одно, на выходе – нечто совершенно иное) и работаете уже с ДРУГОЙ сущностью...

Можно ли жить без всего этого Щастья? ;)
Дык кто ж вам запрещает?... Тока где-то я прочитал оченна умные слова, что "всякий компромис есть отложенная катастрофа"...
Тока вот не надо начинать закидывать меня "конкретными примерами кода"! :о)
Обычно это – выхваченные из контекста куски, совершенно оторванные от полной логики архитектуры... :о)

Почему в Обероне много чего нет, а type test и type guard – есть?
Какая совместимость, и с чем, если это разработанная полностью с нуля аппаратно-программная система?
Я Оберон не изобретал... :о)
Что касается Оберона (конкретно – Активного), то я до сих пор слабо представляю, что это такое и зачем оно нужно в этом языке?... Собсна, по этой причине, почти и не пользовался этим. Как впрочем, и в других языках... Причём, - опять-таки, о чём мы говорим? - о конкретных операциях преобразований скалярных типов или – о поддержке ООП-средств реализации понятия "поддерживаемый интерфейс"?

Действительно, в каждый фиксированный момент времени ячейка памяти может содержать данные одного типа. Но это не значит что всю её жизнь это должен быть один тип.

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

А ещё бывают преобразования типа. Для скалярных типов они обычно встроены в язык программирования.

Можно ли жить без всего этого Щастья? ;)

Почему в Обероне много чего нет, а type test и type guard - есть?

Какая совместимость, и с чем, если это разработанная полностью с нуля аппаратно-программная система?

Ответ на »сообщение 4496« (captain cobalt)
___________________________
Кроме того, до тех пор, пока средствами языка можно добиться двоякого толкования определённого места памяти, успеха в верификации никто и нигде не добьётся
...
Однозначное толкование участка памяти – одна из составляющих "соответствия интерфейсам".

А зачем нужен полиморфизм в ООП?
А зачем нужны type test и type guard в Обероне?
Различное толкование памяти необходимо!
...но контролируемым образом.

Нет, капитан, содержимое памяти должно толковаться только так, а не иначе! Просто по причине того, что ничего другого, одновременно с данным своим содержимым, она не может содержать... :о)
А контролируемый доступ как раз и осуществляется через полиморфизм, вернее, через соглашения о соответствии объекта некоторым интерфейсам. Реализации методов заданных интерфейсов интерпретируют внутреннее содержание (представление) данных объекта для внешних "потребителей" (и обратно). А уж оные потребители вольны (в рамках заявленных объектом реализаций интерфейсов) трактовать объект, как им заблагорассудится...
А пресловутые type test и type guard (и не только в Обероне) как раз и являются вынужденной мерой в связи с нашими уступками в сторону "гибридности", "совместимости" и разных прочих ретрог(р)ад(н)остей... :о) – это просто свидетельство того факта, что на каком-то этапе мы вынуждены были "просочиться" либо через неООП-код, либо через ООП-код в неправильно спроектированной архитектуре...

>>>>> ... предприятие опять потерпит крах... :о)

>>>> Это замечательно.

>>>  Да ничего замечательного! :о)

Не в этом смысле. ;)

Кроме того, до тех пор, пока средствами языка можно добиться двоякого толкования определённого места памяти, успеха в верификации никто и нигде не добьётся
...
Однозначное толкование участка памяти – одна из составляющих "соответствия интерфейсам".

А зачем нужен полиморфизм в ООП?

А зачем нужны type test и type guard в Обероне?

Различное толкование памяти необходимо!
...но контролируемым образом.

Ответ на »сообщение 4494« (captain cobalt)
___________________________
Это замечательно.
Да ничего замечательного! :о) Кто ж вам за здорово живёшь будет начинать думать? "Пилите, Шура, пилите!" или – ещё точнее: "Ты, Жора, жарь, а рыба – будет." :о)

Что такое верифицирующий компилятор?
Каким образом он будет "побуждать программистов"?
Почему имеющиеся компиляторы "не побуждают"?
Этого и сам Хоар, скорее всего не знает. По тому, что появлялось в печати, всё опять сведётся к разработке кучи рекомендаций к построению кода, что бы такой компилятор мог его проверить на соответствие неким "спецификациям", выраженным в некоем "формализованном виде"...
То есть от Си/Си++ мы таки отказаться не можем, хотя сами говорим, что "доказать корректность хотя бы программ на языке Си++ ... невозможно". Но что останется от Си++ после "приведения их к виду и стандартам", воспринимаемым таким ВК, я не представляю.
Есть три пути создания ПО для конкретной предметной области:
1) создание специализированного высокоуровневого языка
2) создание специализированных библиотек
3) написание всего "с полным погружением", то есть невычленение "бизнес-логики" как отдельной сущности, то есть вся программа пишется только для решение конкретной данной задачи из нашей области
От 1) до 3) степень надёжности кода падает, возможность расширяемости и уровень "гибкости" – растут.
Середина, скорее всего – библиотеки, предусматривающие определённые механизмы расширения (архитектура, описания, инструментарий). Теперь остаётся проверить надёжность самих этих библиотек.
Но тут один маленький нюансик есть. Всё дело в том, что Си++ (в наследство от Си) досталось такое "весёленькое" качество, как перенос низкоуровневых абстракций, примитивов и механизмов на уровень приложений. То есть классы есть, а реализация операций опирается на довольно низкоуровневые понятия, позволяющие неоднозначное толкования содержимого ячеек памяти и манипуляций над ними...
Не зря же в самых современных языках ссылки на что-либо, кроме объектов, массивов и строк запрещены и строго контролируется их соответствие...
Кроме того, до тех пор, пока средствами языка можно добиться двоякого толкования определённого места памяти, успеха в верификации никто и нигде не добьётся - у нас просто взрывоподобно растёт набор вариантов толкования состояния элементов системы... Это настолько важно, что даже отцы-основатели Юникса и Си приняли очень радикальное средство в Лимбо: там при операции ref ("дать ссылку на...") возвращается ссылка НА КОПИЮ ОБЪЕКТА-аргумента ref... Интересно, правда?! :о) Какие последствия это тянет за собой, с точки зрения архитектурных решений и повышения надёжности, – додумайте сами... :о)
Однозначное толкование участка памяти – одна из составляющих "соответствия интерфейсам".
Если система обладает средствами, позволяющими "обходить" оговоренные интерфейсы, обещая при этом "повышение производительности" – этими средствами обязательно будут пользоваться. Сама Мысль о том, что возникновение потребности в "оптимизации" – первейший признак неправильно спроектированной архитектуры системы, людей ОЧЕНЬ редко посещает...
"Заставить" или "побудить" программиста можно только битьём по рукам. На всех уровнях. Вон те же смолтокеры, уж насколько их язык "не гибкий" и "ограниченный" (с точки зрения Си++ !), ан-нет, смотришь: чуть ли не в перманентной нирване... :о)
Или лисперы...
Или фортеры...

Просто на поверку получается, что средства языка, явно поддерживающие архитектурные решения "в большом", в итоге, оказываются неизмеримо ценнее набора "синтаксического сахара" вроде *а++ или возможности опускания break в ветвях switch... А "современные компиляторы" как раз и поощряют (и направляют свои усилия на) удовлетворение  программистами частными "языковыми изысками", а не на "поощрение" проектирования систем. За очень редким исключением...

Это замечательно.

Но возникают вопросы.

Что такое верифицирующий компилятор?
Каким образом он будет "побуждать программистов"?
Почему имеющиеся компиляторы "не побуждают"?

Ответ на »сообщение 4492« (captain cobalt)
___________________________
Давайте поговорим о Верифицирующих Компиляторах
Если судить по Хоару:  ...
VC изначально будет побуждать программистов четко формулировать спецификации еще перед созданием кода, с учетом необходимого уровня формализации, позволяющей использовать автоматизированные методы проверки корректности программы.
... предприятие опять потерпит крах... :о)

Давайте поговорим о Верифицирующих Компиляторах.

Какова постановка задачи верифицирующего компилятора?