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

>>>Скажите, а как отличить обычный, рядовой ASSERT от необычного? Необычный надо поставить куда-то хитрым образом? И тогда компилятор поймет, что его надо реинжинирить в абстракцию?

Никаких необычных ASSERT-ов не надо: ASSERT пусть будет самый обычный. :)
Компилятор может выделить абстракцию, например, по размещению ASSERT в самом начале процедуры.
Семантика при этом остается прежней.
Нормальная процедура Sqrt и так пишется с ASSERT-ом. В сущности, теперь может добавиться только контроль констант в compile-time. Как мне кажется, в этом пункте Эйфель может предложить практически то же самое.

Перерыв до завтра. :)

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

Конкретизация этого "декларатива" (различные ограничения, контроль) возложена Виртом на РЕАЛИЗАЦИИ языка, т.е. на разработчиков компиляторов (систем программирования).

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

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

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

Автоматическая генерация DEFINITION из реализации -- это очень плохо. Для промышленного программирования. Для индивидуального -- сойдет. Проблема не в рассинхронизации, а в контроле на уровне языка. Модула-2 с этим отлично справлялась. Маркировка реализации в Обероне -- это видимое удобство. Для вариативности реализаций под один интерфейс и для использования интерфейса в качестве упрощенной спецификации (зафиксированной "приказом"!) приходится стоять на ушах? А во имя чего? Все равно DEFINITION существует. А рассинхронизация элементарно контролируется.

В DEFINITION автоматически получаем что-то вроде:

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

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

>>>Споры по языкам (что можно, что нельзя) должны решаться на уровне их официальных описаний (стандартов). Любое привлечение для этого компилятора есть снятие границы между языком и его реализацией.

Так мы с того начали, что в описаниях Вирта это не совсем так.
Вы сами констатируете в »сообщение 5716«:
Если почитать выполненные Виртом лаконичные описания языков, то можно заметить, что там рекомендациями вроде бы особо и не пахнет. Но при этом Вирт выбрал форму изложения, не близкую к описанию стандартов языков ("императивную", настаивающую на неукоснительном исполнении), а скорее рекомендательную ("декларативную"). Т.е. рекомендации по форме и требования по содержанию. Конкретизация этого "декларатива" (различные ограничения, контроль) возложена Виртом на РЕАЛИЗАЦИИ языка, т.е. на разработчиков компиляторов (систем программирования).
Я просто пытаюсь осмыслить этот факт.

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

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

>>>Ясно, что ASSERT в самом начале процедуры (до первого оператора) семантически эквивалентен require.

А кто его туда ставит, в начало? Программист? А как это соотносится с декларацией предусловий в интерфейсе? На уровне комментария? А кто проверяет отклонения (рассинхронизацию) деклараций в комментариях от реальной реализации?

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

PROCEDURE Sqrt* (x: REAL): REAL;
  ...
BEGIN ASSERT(x >= 0.0);
  ...
END Sqrt;

В DEFINITION автоматически получаем что-то вроде:

PROCEDURE Sqrt (x: REAL): REAL; require (x >= 0.0);

Ответ на »сообщение 5728« (Стэн)
___________________________

А можно поинтересоваться, кто и по каким причинам перестал делать различие между языком и его реализацией?

Под словом "мы" я подразумевал программистское сообщество. Сложившуюся практику. Печальную. Споры по языкам (что можно, что нельзя) должны решаться на уровне их официальных описаний (стандартов). Любое привлечение для этого компилятора есть снятие границы между языком и его реализацией.

Не так давно оказался вовлеченым в дискуссию, где оппонентом был специалист по языкам программирования. К моему удивлению он стал приводить примеры реакции конкретного компилятора вместо точного указания пункта в описании языка. И это не исключение. По моим наблюдениям.

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

Ясно, что ASSERT в самом начале процедуры (до первого оператора) семантически эквивалентен require.

А кто его туда ставит, в начало? Программист? А как это соотносится с декларацией предусловий в интерфейсе? На уровне комментария? А кто проверяет отклонения (рассинхронизацию) деклараций в комментариях от реальной реализации?

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

>>>Не стоит даже зацикливаться на настройке реализации языка. Либо абстракция есть в языке и им контролируется. Либо она контролируется "вручную" (вне языка).

Утверждения (как таковые) были предложены, кажется, еще Тьюрингом.
ASSERT -- часть языка Оберон, поэтому в языке ничего менять не надо.
Ясно, что ASSERT в самом начале процедуры (до первого оператора) семантически эквивалентен require.
Автоматическая генерация DEFINITION может позволить контролировать предусловия процедуры во время компиляции импортирующего модуля.
А что еще может нам предложить эйфелевский require?

Ответ на »сообщение 5727« (Руслан Богатырев)
___________________________
>>> Сначала мы перестали делать различия между языком и его конкретной реализацией.
А можно поинтересоваться, кто и по каким причинам перестал делать различие между языком и его реализацией?
Так как на практике очень часто приходится сталкиваться с тем, что есть спецификация языка, которая некоторые моменты оставляет на откуп реализации. И есть конкретные реализации в которых, по каким-то загадочным причинам, все неточности и недосказанности спецификации, понимаются совершенно по-разному...

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

Если мы (например, как создатели компилятора) предоставим возможность выбора строгого варианта, то require мало чем будет отличаться от ASSERT в начале процедуры. (Особо хотелось бы обратить внимание на ту роль, которую при этом может сыграть автоматическая генерация DEFINITION.)

Он будет принципиально отличаться. Сначала мы перестали делать различия между языком и его конкретной реализацией. Затем между реализацией и системой программирования. Если имитация, например, require будет выполняться на уровне прагм компилятора (конкретного), то это неявно приведет к новому ЯЗЫКУ. Другая реализация того же (базового) языка такое ведь не гарантирует. Если есть ключевые абстракции (как например, инварианты), то их имитация что на уровне прагм, что на уровне "ручного" программирования -- это эрзац.

Вопрос в том, какие критерии выбраны теми, кто определяет, сколь ключевой является та или иная особенность (абстракция, конструкт). Видятся три варианта воплощения новой абстракции:
1. имитация ручками (нет контроля семантики на уровне языка)
2. через средства системы программирования (или реализации языка, те же прагмы компилятора)
3. через новый язык.

Не стоит даже зацикливаться на настройке реализации языка. Либо абстракция есть в языке и им контролируется. Либо она контролируется "вручную" (вне языка).

Попробуйте убедить UNIX-программистов в том, что выбор языка важен для ОС. Это непросто. Для них язык неважен, но Си -- практически идеал. Подставим вместо Си в реализацию UNIX, скажем, Модулу-2, и мы увидим разницу. Существенную. А ведь всё, что есть в Модуле-2, можно с грехом пополам имитировать на Си.