[Oberon rev 2013] CASE

[valexey_u]

По поводу CASE - самое смешное, что если результат expression'a не соответствует ни одному из label, то программа спокойно продолжает работать. То есть HALT'а не будет:

Код: [Выделить]

x := 42;
CASE x OF
    1: ret := int
  | 2: ret := real
  | 3: ret := char
END
Это абсолютно валидный рабочий код с точки зрения современного Оберона.

Ну а почему здесь должен быть HALT?
Ведь раз CASE OF просто синтаксических сахар для IF-ELSIF, то этот код эквивалентен такому:

Код: [Выделить]

x := 42;
IF    x = 1 THEN ret := int
ELSIF x = 2 THEN ret := real
ELSIF x = 3 THEN ret := char
ENDТут же всё в порядке, ветка ELSE не является обязательной...

Ну, насколько я понимаю, это не совсем так. Например вот тут изложены некие соображения: http://forum.oberoncore.ru/viewtopic.php?f=6&t=2284#p41338

Которые местами не верные, но любопытные. (Вирт вернул символьные литералы в качестве label в CASE, также в Обероне не требуется именно плотная упаковка этих самых label).

[akron1]

Ну а почему здесь должен быть HALT?
Ведь раз CASE OF просто синтаксических сахар для IF-ELSIF, то этот код эквивалентен такому:

Код: [Выделить]

x := 42;
IF    x = 1 THEN ret := int
ELSIF x = 2 THEN ret := real
ELSIF x = 3 THEN ret := char
ENDТут же всё в порядке, ветка ELSE не является обязательной...

А вот компилятор Astrobe считает что должен быть HALT

[valexey_u]

Ну а почему здесь должен быть HALT?
Ведь раз CASE OF просто синтаксических сахар для IF-ELSIF, то этот код эквивалентен такому:

Код: [Выделить]

x := 42;
IF    x = 1 THEN ret := int
ELSIF x = 2 THEN ret := real
ELSIF x = 3 THEN ret := char
ENDТут же всё в порядке, ветка ELSE не является обязательной...

А вот компилятор Astrobe считает что должен быть HALT

Чем противоречит описанию языка.

[ilovb]

Без ELSE должен быть HALT по идее.

[valexey_u]

Без ELSE должен быть HALT по идее.

Там ELSE не допустим синтаксически. См описание языка.

Также там нет ничего про HALT.

В общем, не надо фантазировать и придумывать то, чего в языке нет :-)

[vlad]

Вообще CASE без перечислимых типов (а-ля енум), с которыми он мог бы работать в паре и проверять все вхождения - имеет исчезающе мало смысла. Синтаксический сахарок, без которого суровые оберонщики вполне обойдутся.

[ilovb]

Без ELSE должен быть HALT по идее.

Там ELSE не допустим синтаксически. См описание языка.

Также там нет ничего про HALT.

В общем, не надо фантазировать и придумывать то, чего в языке нет :-)

Тык потому и говорю "по идее"
Просто без HALT это странный CASE получается.
Придется эмулировать через IF с явным HALT

[ilovb]

. If the value of the expression does not occur as a label
of any case, the statement sequence following the symbol ELSE is selected, if there is one.
Otherwise it is considered as an error.

http://store.oberoncore.ru/lib/book/report_oberon.pdf

Да, текст явно выпилен. Может он лишнее захватил? 

[valexey_u]

. If the value of the expression does not occur as a label
of any case, the statement sequence following the symbol ELSE is selected, if there is one.
Otherwise it is considered as an error.

http://store.oberoncore.ru/lib/book/report_oberon.pdf

Да, текст явно выпилен. Может он лишнее захватил? 

Навряд ли. Он же грамматику поправил (как минимум в двух местах, а также в примере, а также в словесном описании) - нет там больше ELSE. Ну, то есть в принципе. Это начиная с rev 2007/2008.

[ilovb]

Странно все это. Он бы хоть свои соображения попутно записывал...
А так ничего не понято.

Ну т.е. я понимаю логику HALT в CASE. И пользуюсь этим на практике.
В 1С эмулирую так:
Если .. Тогда
....
ИначеЕсли ... Тогда
....
Иначе
ВызватьИсключение "...";
КонецЕсли;

Это паттерн обработки сообщений с гарантом того, что конструкция "знает" все типы сообщений.
Это здорово помогает при отладке.

И CASE я воспринимал в основном в этом ракурсе.
Теперь же получается что роль у него другая.
Когнитивный диссонанс...

Хотя остается маневр типа такого:

x := 42;
CASE x OF
    1: ret := int
  | 2: ret := real
  | 3: ret := char
END
ASSERT(x < 4)

[ilovb]

Навряд ли. Он же грамматику поправил (как минимум в двух местах, а также в примере, а также в словесном описании) - нет там больше ELSE. Ну, то есть в принципе. Это начиная с rev 2007/2008.

Ммм. Я не про ELSE.
А про:

Otherwise it is considered as an error.

Ну т.е. типа текст про ELSE выпилил, а вот про этот момент забыл упомянуть...

[kkkk]

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

[valexey_u]

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

В этом случае эта опечатка там начиная с 2007 года как минимум.

В текущем репорте я не вижу там поводов для UB. То есть ситуация полностью аналогичная IF .. ELIF .. ELSE. Если ни одно из условий не подошло, значит не подошло. Ничего страшного. Выполняется следующий statement.

Нет, в принципе конечно идея сделать жесткой конструкцию IF ELIF ELSE (то есть ELSE обязателен) равно как и CASE .. ELSE, довольно интересна. В этом случае будут рассматриваться гарантированно все случаи, все ветки всегда. И вообще лежит в том же русле что и RETURN не как statement, а как часть синтаксиса функции.

Но Вирт по какой-то причине этого не сделал.

[kkkk]

Ничего удивительного, что эта недосказанность существует давно. При редактировании "Алгоритмов и структур данных" для Модулы-2 у него были похожие проблемы, о чем можно прочитать в предисловии переводчика.

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

[valexey_u]

Ничего удивительного, что эта недосказанность существует давно. При редактировании "Алгоритмов и структур данных" для Модулы-2 у него были похожие проблемы, о чем можно прочитать в предисловии переводчика.

Ну, насколько я вижу, Вирт сейчас не на пустом месте ревизии Оберона клепает - как минимум он похоже взаимодействует с разработчиками Astrobe как-то. То есть фидбек у него есть.

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

Ну, с другой стороны про IF-statement сказано, что:

If no guard is satisfied, the statement sequence following the symbol ELSE is executed, if there is one

А что делать если ELSE нет, также не сказано. Может трап должен быть, а может и нет.

Если подходить формально, то да, в репорте должно быть явно оговорено, что делать "в конце" каждого statement'a в разных случаях (например когда ни один из ожидаемых исходов не реализовался). Переходить к следующему или же трапаться, или что-то там еще. В текущем репорте описан только синтаксис для statement sequence, семантика не описана.