Оберон-07

Дмитрий Сурков

Борис Рюмшин писал(а):

А что делать в случае:

Код:

PROCEDURE Check(IN rec: Record): INTEGER;
BEGIN
  IF cond0 THEN RESULT := res0
  ELSIF cond1 THEN RESULT := res1
  ELSIF cond2 THEN RESULT := res2
  END
END Check;

Это ошибка, о которой должен сообщить компилятор.

Борис Рюмшин

Дмитрий Сурков писал(а):

Это ошибка, о которой должен сообщить компилятор.

Понятное дело, что ошибка... вот только отслеживать такое в компиляторе невозможно. Как определить, что условие может быть таким, что ни один вариант не подойдёт (у меня, возможно, склероз, но мы где-то здесь это уже обсуждали)? Формально - процедура корректна.

Борис Рюмшин

На всякий случай: ELSE не является обязательным и делать его таковым не рентабельно.

Дмитрий Сурков

Борис Рюмшин писал(а):

Дмитрий Сурков писал(а):

Это ошибка, о которой должен сообщить компилятор.

Понятное дело, что ошибка... вот только отслеживать такое в компиляторе невозможно. Как определить, что условие может быть таким, что ни один вариант не подойдёт (у меня, возможно, склероз, но мы где-то здесь это уже обсуждали)? Формально - процедура корректна.

Формально оператор IF..THEN корректен, а некорректна процедура. Компилятор сообщит не об отсутствии блока ELSE, а о возможной ситуации, когда значение RESULT неопределено. Это легко отслеживается и ничем не отличается от проверки инициализации OUT-параметров.

Борис Рюмшин

Хорошо, чем с точки зрения компилятора отличаются эти два варианта:

Код:

PROCEDURE Check(IN rec: Record): INTEGER;
BEGIN
  IF cond0 THEN RESULT := res0
  ELSIF cond1 THEN RESULT := res1
  ELSIF cond2 THEN RESULT := res2
  END
END Check;

и

Код:

PROCEDURE Check(IN rec: Record): INTEGER;
BEGIN
  IF cond0 THEN RESULT := res0
  ELSIF cond1 THEN RESULT := res1
  ELSE RESULT := res2
  END
END Check;

Борис Рюмшин

Это, кстати, к вопросу об оптимизации и усложнении компилятора. Для подробного анализа подобных выкрутасов потребуется несколько проходов, и не исключено, что в результате ошибок при конструировании такого компилятора, возникнут нетривиальные побочные эффекты с синтаксическими конструкциями.

Vlad

Valery Solovey писал(а):

Vlad писал(а):

А зачем?

Это ж так не удобно - отслеживать изменения какой-то там переменной. Намного удобнее проверять результат каждой под-операции.

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

Да я не про тесты. Я про то, что результат, как правило, получается не в результате каких-то инкрементальных действий над одной переменной, а как комбинация результатов промежуточных вычислений. Поэтому проверяется, как правило, результаты промежуточных вычислений. И RETURN этому никак не мешает.

Valery Solovey писал(а):

А как насчёт того факта, что признаком дурного тона при программировании на Си считается объявлять переменные где-либо не в начале подпрограммы?

Не знаю как на С, а на С++ объявление по месту - это как раз признак хорошего тона. Подозреваю, что ты наслушался советов старого паскалиста

Valery Solovey писал(а):

К тому же, объявления переменных, распределённые по всей подпрограмме, тоже создают проблемы.

Какие?

Valery Solovey писал(а):

Vlad писал(а):

Например, основную работу делает вложенная процедура, ее результат проверяется и возвращается внешней.

Получается оригинальная динамическая проверка, которая иногда будет очень сказываться на производительности. А откуда уверенность, что внешняя процедура работает верно? Её тоже надо проверять. Причём, не факт, что она будет проще вложенной.

Внешняя процедура будет иметь один RETURN и проверку постусловий (и больше ничего). Внутренняя - множество RETURN. Какая еще динамика?

Борис Рюмшин

В Оберон-07 (пора его вспомнить в его ветке

) RETURN будет зажат в виде такой конструкции:

ProcedureBody = DeclarationSequence ["BEGIN" StatementSequence] ["RETURN" expression] "END"

Дмитрий Сурков

Борис Рюмшин писал(а):

Хорошо, чем с точки зрения компилятора отличаются эти два варианта:

Код:

PROCEDURE Check(IN rec: Record): INTEGER;
BEGIN
  IF cond0 THEN RESULT := res0
  ELSIF cond1 THEN RESULT := res1
  ELSIF cond2 THEN RESULT := res2
  END
END Check;

и

Код:

PROCEDURE Check(IN rec: Record): INTEGER;
BEGIN
  IF cond0 THEN RESULT := res0
  ELSIF cond1 THEN RESULT := res1
  ELSE RESULT := res2
  END
END Check;

Это, кстати, к вопросу об оптимизации и усложнении компилятора. Для подробного анализа подобных выкрутасов потребуется несколько проходов, и не исключено, что в результате ошибок при конструировании такого компилятора, возникнут нетривиальные побочные эффекты с синтаксическими конструкциями.

Нужно ли было Вирту усложнять компилятор, чтобы отказаться от упреждающего объявления указательных типов данных перед их использованием? Нужно ли усложнять компилятор для отслеживания обращений к неинициализированным переменным? Нужно ли усложнять компилятор для отслеживания неинициализированной переменной RESULT?

Мне кажется вопрос стоит по-другому. Упростит ли это для программиста написание и чтение кода? Да. Тогда нужно этот компилятор усложнить. Вирт сохранил оператор RETURN, ограничив его использование, ради совместимости с существующим Обероном. Элегантно решил проблемку. Однако, если бы я, скажем, создавал на основе Оберона свой новый язык, то я бы выбрал вариант с псевдопеременной RESULT.

Vlad

Борис Рюмшин писал(а):

В Оберон-07 (пора его вспомнить в его ветке

) RETURN будет зажат в виде такой конструкции:

ProcedureBody = DeclarationSequence ["BEGIN" StatementSequence] ["RETURN" expression] "END"

А, ну вот, значит я ошибался

Здравый смысл все-таки проиграл

Пришел лесник и всех разогнал

Можно закрывать ветку.

Илья Ермаков

Зато восторжествовала правильность - в виде структурного программирования.
А здравый смысл штука относительная. Он, к примеру, может насоветовать, что Солнце вращается вокруг Земли, и что глупо верить науке вопреки собственным глазам... :-)

Сергей Губанов

Дмитрий Сурков писал(а):

Это легко отслеживается и ничем не отличается от проверки инициализации OUT-параметров.

Я раньше тоже так думал, но это не так. Компилятор может лишь заподозрить отсутствие инициализации, но выяснить это точно можно лишь во время исполнения программы.

Трурль показал простой пример:

if (condition) outParameter = ...;
if (!condition) outParameter = ...;

здесь компилятор ругается на то, что outParameter может быть не инициализирован хотя он инициализирован.

Info21

Vlad писал(а):

... Пришел лесник и всех разогнал.

Вирт сделал ревизию Оберона на основе предложений небольшой группы тех, кто на Оберонах неплохо преуспел. Так что эти изменения (LOOP на цикл Дейкстры, ужесточение RETURN) -- глас квалифицированного народа.

Понятно, что тем, кого не спросили, обидно

Когнитивный диссонанс...

Vlad

info21 писал(а):

Вирт сделал ревизию Оберона на основе предложений небольшой группы тех, кто на Оберонах неплохо преуспел. Так что эти изменения (LOOP на цикл Дейкстры, ужесточение RETURN) -- глас квалифицированного народа.

Гхм. Мне вот что непонятно. Очевидно, что тот "кто неплохо преуспел" если и пишет что-то на обероне, то на какой-то конкретной реализации. Причем эта реализация, скорее всего не виртовская, а того самого народа. Соответственно, чтобы внести изменения в язык "лесник" не нужен (ББ тому яркий пример).

Info21

Кто термин "лесник" ввел, тому и разбираться.

PGR

Есть ли какие-нибудь новости об Обероне-07 (или уже -08) ?

Geniepro

PGR писал(а):

Есть ли какие-нибудь новости об Обероне-07 (или уже -08) ?

Кажется описание Оберона-07 тем временем было тихо-мирно опубликовано:
http://www.inf.ethz.ch/personal/wirth/A ... onARM.html

Info21

PGR писал(а):

Есть ли какие-нибудь новости об Обероне-07 (или уже -08) ?

Насколько я понимаю, он будет аппендиксом в новом издании Compiler Construction, которое as of last Fall готовилось в печати.
Издательство Oldenbourg (Германия).

PGR

Непонятно, WITH остался или нет?
В Summary сказано, что его выкинули, а в Oberon-07 Report он остался...

Александр Ильин

Лучше бы FOR выкинули.

Объясните мне кто-нибудь, откуда взялись PACK с UNPK, и где они могут пригодиться.

OberonCore

Оберон-07

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