Ответ на »сообщение 5741« (Руслан Богатырев)
___________________________

>>>И еще такой нюанс: а есть ли вообще ASSERT в классическом Обероне? :)

Судя по описанию, нет. Также как и экспорта только для чтения.
ASSERT отсутствует также и в недавней электронной книге "Programming in Oberon" (2004).
Видимо, в теле Sqrt надо было писать что-то вроде

IF (x < 0.0) THEN HALT END;

Но я бы не стал отказываться ни от ASSERT, ни от экспорта read-only.
Оберон во многом построен на утверждениях: разыменование указателя предполагает утверждение о том, что указатель не нулевой; приведение типа записи предполагает type-guard; и т.д.
ASSERT -- явное выражение программистского инварианта.

Ответ на »сообщение 5735« (Руслан Богатырев)
___________________________

Конкретизация конкретизации рознь. Я это пояснил в абзаце про то, кто и что считает ключевой абстракцией в отношении данного языка. Вирт отдает на откуп не так много. У него весьма определенно дано описание языка (требования, а не рекомендации). Рекомендательно язык в описании просто выглядит внешне, по изложению (по форме).

Как-то странно всё это...
Как можно отличить требование, маскирующееся под рекомендацию, от просто рекомендации?
И как сам Вирт объясняет то, что его рекомендации на самом деле -- требования? Может это всего лишь Ваш домысел?

Ответ на »сообщение 5707« (pepper)
___________________________
>>>Не бывает таких врачей.

Во время бума вокруг экпертных систем в 70-80-е чуть ли не в каждой статье упоминался MYCIN. Эта система была разработана хорошим медиком, умеющим программировать.
В те годы было выпущено множество абсолютно бесполезных ЭС, авторы которых, будучи программистами, разбирались в предметной области куда хуже, чем Шортлифф в медицине.

Хочу вставить свои пять копеек в дискуссию о циклах.
Тут сталкиваются, на мой взгляд, синтаксический и симантический подход к программированию.
Если рассматривать программирование, как раздел математики, то можно необращать вниманиея на такие мелочи, как повторение кода или дополнительные проверки. Соблюдение строгих правил дает возможность формального анализа и, соответственно высокой надежности.
Если же подходить с точки зрения эффективности и, как ни странно, соответствия смыслу, получаются странные выводы.
Оператор цикла очень часто используется для поиска. Но после поиска всегда стоит проверка "нашли/ненашли". И в алгоритме поиска она всегда есть. И именно эта конструкция провоцирует создание "конструкции с двумя выходами".
Может для этого варианта нужно было создать отдельную конструкцию в структурном программировании? Описать эдакий цикл For-Else :)

Ответ на »сообщение 5725« (Руслан Богатырев)
___________________________
Похоже, у нас несколько разные представления о том, что такое спецификация.
Да, это так. Наиболее общее определение я нашел в Википедии:
Специфика?ция — (от англ. Specification) инженерный термин, обозначающий набор требований и параметров, которым удовлетворяет некоторая сущность.
Ни в одном определении не оговаривается, что спецификация должна быть составлена на формально-строгом языке, а значит пригодна для интепретации как человеком, так и компьютером .
Для меня этим и отличается спецификация от программы, что первая требует человеческого вмешательства для доформализации, а вторая может непосредственно интерпритироваться компьютером. Все спецификации, которые я видел, были написаны на естественном языке с привлечением неформализованного графического представления.
Как только мы создали для некоторой прикладной области формальный язык, так мы превратили специалиста в специалиста-программиста, которому не нужен посредник для общения с компьютером. До этих пор потребуется спецификация, как посредник между специалистом и программистом. И будет она постоянным источником разночтений и вариантов толкований.

Ответ на »сообщение 5738« (AVC)
___________________________

Неужели компилятор не отличит аргумент процедуры от других переменных? :)
Из приведенного утверждения можно тем не менее вычленить require (x > 0).

Рассмотрите еще такой случай. Контроль предусловий программист возложил на специальную процедуру-функцию IsCorrect, которая принимает в качестве своих параметров параметры Sqrt, а возвращает значение TRUE или FALSE.

ASSERT(IsCorrect(x));

Как это будет реинжинирить компилятор (причем его схему должен в точности знать программист, чтобы понимать всю "химию"). Как низко он падет? Полезет разбираться в тело процедуры-функции IsCorrect? Или просто не будет указывать предусловий в интерфейсе ("чего c тебя, программиста, взять")?

И еще такой нюанс: а есть ли вообще ASSERT в классическом Обероне? :)

Ответ на »сообщение 5739« (Руслан Богатырев)
___________________________

Но это разные инварианты!

И самое главное -- всё перевернуто с ног на голову. Приходится не из спецификации получать реализацию (что должно быть), а наоборот. Т.е. реинжинирить, наполняя компилятор семантикой имитации абстракций. А зачем?

Ответ на »сообщение 5738« (AVC)
___________________________

Из приведенного утверждения можно тем не менее вычленить require (x > 0).

Но это разные инварианты!

Ответ на »сообщение 5737« (Руслан Богатырев)
___________________________

ASSERT ((x > 0) AND done);

Эта done вылезет (благодаря "находчивости" компилятора) в интерфейс, где на нее внешний программист будет смотреть как баран на новые ворота.

Уже думал.
Неужели компилятор не отличит аргумент процедуры от других переменных? :)
Из приведенного утверждения можно тем не менее вычленить require (x > 0).

Теперь точно до завтра! :)

Ответ на »сообщение 5736« (AVC)
___________________________

Никаких необычных ASSERT-ов не надо: ASSERT пусть будет самый обычный. :)

Такая эквилибристика добром вряд ли закончится. Подумайте над такой простой вещью. В ASSERT (в первом операторе процедуры) могут быть указаны не только формальные параметры, но и глобальные переменные, которые не видны вне модуля (не экспортируемые).

ASSERT ((x > 0) AND done);

Эта done вылезет (благодаря "находчивости" компилятора) в интерфейс, где на нее внешний программист будет смотреть как баран на новые ворота.