OberonCore

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

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

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

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

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

и

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

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



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



Какие?



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

В Оберон-07 (пора его вспомнить в его ветке ) RETURN будет зажат в виде такой конструкции:

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

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

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

А, ну вот, значит я ошибался Здравый смысл все-таки проиграл Пришел лесник и всех разогнал Можно закрывать ветку.

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

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

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

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

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

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

Понятно, что тем, кого не спросили, обидно
Когнитивный диссонанс...

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

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

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

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

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

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

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

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