Oberon space
General Category => Общий раздел => Тема начата: valexey_u от Ноябрь 06, 2013, 01:07:53 pm
-
По поводу 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).
-
Ну а почему здесь должен быть 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
-
Ну а почему здесь должен быть 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
Чем противоречит описанию языка.
-
Без ELSE должен быть HALT по идее.
-
Без ELSE должен быть HALT по идее.
Там ELSE не допустим синтаксически. См описание языка.
Также там нет ничего про HALT.
В общем, не надо фантазировать и придумывать то, чего в языке нет :-)
-
Вообще CASE без перечислимых типов (а-ля енум), с которыми он мог бы работать в паре и проверять все вхождения - имеет исчезающе мало смысла. Синтаксический сахарок, без которого суровые оберонщики вполне обойдутся.
-
Без ELSE должен быть HALT по идее.
Там ELSE не допустим синтаксически. См описание языка.
Также там нет ничего про HALT.
В общем, не надо фантазировать и придумывать то, чего в языке нет :-)
Тык потому и говорю "по идее"
Просто без HALT это странный CASE получается.
Придется эмулировать через IF с явным HALT
-
. 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
Да, текст явно выпилен. Может он лишнее захватил? :)
-
. 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.
-
Странно все это. Он бы хоть свои соображения попутно записывал...
А так ничего не понято.
Ну т.е. я понимаю логику HALT в CASE. И пользуюсь этим на практике.
В 1С эмулирую так:
Если .. Тогда
....
ИначеЕсли ... Тогда
....
Иначе
ВызватьИсключение "...";
КонецЕсли;
Это паттерн обработки сообщений с гарантом того, что конструкция "знает" все типы сообщений.
Это здорово помогает при отладке.
И CASE я воспринимал в основном в этом ракурсе.
Теперь же получается что роль у него другая.
Когнитивный диссонанс...
Хотя остается маневр типа такого:
x := 42;
CASE x OF
1: ret := int
| 2: ret := real
| 3: ret := char
END
ASSERT(x < 4)
-
Навряд ли. Он же грамматику поправил (как минимум в двух местах, а также в примере, а также в словесном описании) - нет там больше ELSE. Ну, то есть в принципе. Это начиная с rev 2007/2008.
Ммм. Я не про ELSE.
А про:
Otherwise it is considered as an error.
Ну т.е. типа текст про ELSE выпилил, а вот про этот момент забыл упомянуть...
-
В отчете о языке не сказано об обработке ситуации, когда значение выражения не соответствует ни одной из меток, следовательно поведение в таком случае не определено в прямом смысле этого слова, и там вполне может быть и аварийный останов. Другое дело, что это осложняет обработку случаев, когда другие варианты возможны. Также в отчете не сказано о том, что метки не могут пересекаться. Возможно, Никлаус Вирт действительно невнимательно отредактировал отчет, такое с ним случалось и прежде.
-
В отчете о языке не сказано об обработке ситуации, когда значение выражения не соответствует ни одной из меток, следовательно поведение в таком случае не определено в прямом смысле этого слова, и там вполне может быть и аварийный останов. Другое дело, что это осложняет обработку случаев, когда другие варианты возможны. Также в отчете не сказано о том, что метки не могут пересекаться. Возможно, Никлаус Вирт действительно невнимательно отредактировал отчет, такое с ним случалось и прежде.
В этом случае эта опечатка там начиная с 2007 года как минимум.
В текущем репорте я не вижу там поводов для UB. То есть ситуация полностью аналогичная IF .. ELIF .. ELSE. Если ни одно из условий не подошло, значит не подошло. Ничего страшного. Выполняется следующий statement.
Нет, в принципе конечно идея сделать жесткой конструкцию IF ELIF ELSE (то есть ELSE обязателен) равно как и CASE .. ELSE, довольно интересна. В этом случае будут рассматриваться гарантированно все случаи, все ветки всегда. И вообще лежит в том же русле что и RETURN не как statement, а как часть синтаксиса функции.
Но Вирт по какой-то причине этого не сделал.
-
Ничего удивительного, что эта недосказанность существует давно. При редактировании "Алгоритмов и структур данных" для Модулы-2 у него были похожие проблемы, о чем можно прочитать в предисловии переводчика.
Возможно я чего-то недопонимаю, но в отчете сказано, что должен быть выполнен список операторов, помеченный меткой, содержащей значение выражения. Что делать, если нужной метки нет, ничего не сказано, что для меня означает неопределенное поведение. При чем буквально - это поведение нигде не определено, значит и полагаться на него нельзя.
-
Ничего удивительного, что эта недосказанность существует давно. При редактировании "Алгоритмов и структур данных" для Модулы-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, семантика не описана.
-
Не на пустом месте да, но невнимательность при редактировании это не отменяет. У меня в документации коллеги такие же дыры находят, хотя я ее сам по горячим следам дописываю.
А что делать если ELSE нет, также не сказано. Может трап должен быть, а может и нет.
Если с такой позиции смотреть, то да - и в CASE не должно происходить останова. Поскольку в IF его точно не должно быть. Хотя кто знает :)
-
А что делать если ELSE нет, также не сказано. Может трап должен быть, а может и нет.
Если с такой позиции смотреть, то да - и в CASE не должно происходить останова. Поскольку в IF его точно не должно быть. Хотя кто знает :)
На самом деле, сколь я помню, HALT при отсутствующем ELSE (то есть когда ничего не случилось из ожидаемого) рассматривался: http://forum.oberoncore.ru/viewtopic.php?f=82&t=3484
Сделать экспериментальный мод для языка не сложно. Но мод сделать мало, нужны еще ресурсы на то, чтобы полноценно это дело обкатать и опробовать. Пока у нас вроде бы ресурсов на это нет - мы Оберон то в последней ревизии еще не обкатали со всех сторон (на разных платформах там, с разными биндингами, для разных задач разными людьми) :-)
-
То были просто размышления. И если для многоветочного он ещё и может иметь смысл, то для одноветочного - это точно перебор, а разное поведение для одной и той же конструкции, в зависимости от конфигурации ясности программе не даст.
-
Также в отчете не сказано о том, что метки не могут пересекаться. Возможно, Никлаус Вирт действительно невнимательно отредактировал отчет, такое с ним случалось и прежде.
Посмотрел репорт 2013 года, - и правда, - нигде не сказано, что метки выбора не должны дублироваться. И всё же я думаю, что если задать Вирту прямой вопрос, то он ответит: "Конечно, не могут дублироваться".
Как писал Патрик:
Оригинальное сообщение о языке [7] чрезвычайно короткое, автор полагается на здравый смысл и интуицию читателя.
-
Также в отчете не сказано о том, что метки не могут пересекаться. Возможно, Никлаус Вирт действительно невнимательно отредактировал отчет, такое с ним случалось и прежде.
Посмотрел репорт 2013 года, - и правда, - нигде не сказано, что метки выбора не должны дублироваться. И всё же я думаю, что если задать Вирту прямой вопрос, то он ответит: "Конечно, не могут дублироваться".
Как писал Патрик:
Оригинальное сообщение о языке [7] чрезвычайно короткое, автор полагается на здравый смысл и интуицию читателя.
Это там еще с 2007 года.
А вот в 1990 году:
The case expression and all labels must be of the same type, which must be an integer type or CHAR. Case labels are constants, and no value must occur more than once. 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.
То есть все привыкли именно вот так CASE в языках Оберон-семейства трактовать (ну, быть может за вычетом ELSE). Но Вирт то вот это все явно удалил. И быть может не просто так? :-)
Надо бы как-то на Вирта таки выйти.
-
Ну, с другой стороны про IF-statement сказано, что:
If no guard is satisfied, the statement sequence following the symbol ELSE is executed, if there is one
А что делать если ELSE нет, также не сказано. Может трап должен быть, а может и нет.
Трапа, конечно же, быть не должно. Иначе, конструкция IF просто перестаёт быть конструкцией ветвления: единственный вариант, который обязательно должен быть выполнен. Но перед началом выполнения должно выполняться какое-то условие. Это же просто ASSERT!
-
Ну, с другой стороны про IF-statement сказано, что:
If no guard is satisfied, the statement sequence following the symbol ELSE is executed, if there is one
А что делать если ELSE нет, также не сказано. Может трап должен быть, а может и нет.
Трапа, конечно же, быть не должно. Иначе, конструкция IF просто перестаёт быть конструкцией ветвления: единственный вариант, который обязательно должен быть выполнен. Но перед началом выполнения должно выполняться какое-то условие. Это же просто ASSERT!
Да нет, не перестает. Просто ELSE или ELIF становится обязательным.
-
Только ELSE ;)
-
Только ELSE ;)
Почему? У тебя может быть ситуация, когда у тебя есть две (или более) ветки, а ELSE не возможен в принципе по логике работы программы. И вот там то и нужен HALT :-)
-
Да нет, не перестает. Просто ELSE или ELIF становится обязательным.
И, согласно текущему определению языка, как минимум один оператор, бессмысленный и беспощадный. А ведь есть банальный ASSERT.
-
Только ELSE ;)
Почему? У тебя может быть ситуация, когда у тебя есть две (или более) ветки, а ELSE не возможен в принципе по логике работы программы. И вот там то и нужен HALT :-)
Ничего не понял. Как ELIF может быть обязательным?
-
Нет, в принципе конечно идея сделать жесткой конструкцию IF ELIF ELSE (то есть ELSE обязателен) равно как и CASE .. ELSE, довольно интересна. В этом случае будут рассматриваться гарантированно все случаи, все ветки всегда. И вообще лежит в том же русле что и RETURN не как statement, а как часть синтаксиса функции.
Но Вирт по какой-то причине этого не сделал.
Мне иногда кажется что мы вавилонскую башню строим. Т.к. разговариваем бывает на разных языках.
:)
Вот эта цитата примечательна тем, что предлагается вариант который имеет полностью противоположный эффект, нежели дает CASE с HALT.
HALT - дает гарантию что выполнение остановится если CASE'у сообщение неизвестно. Т.е. весь профит заключен именно в останове.
Предложенный же тобой вариант, в корне этот профит уничтожает.
И этот вариант как раз никогда не гарантирует что:
будут рассматриваться гарантированно все случаи, все ветки всегда.
Пример:
if msg = m1 then
do1();
elif msg = m2 then
do2();
else
do3();
end;
Даем конструкции новую мессагу m4 и приехали... Кот работает как ни в чем не бывало. И только по побочным эффектам от багов можно будет догадаться, что забыл добавить обработку этой новой мессаги.
-
Судя по информации из PO2013 и исходникам, новый CASE теперь аналог WITH в CP.
При этом он не имеет ELSE. И, похоже, что valexey был прав насчет HALT..., ибо в исходниках я не обнаружил генерацию оного.
-
То есть, будет трап, если условие не удовлетворено?
-
Наоборот. Трапа не будет.
-
Пример:
if msg = m1 then
do1();
elif msg = m2 then
do2();
else
do3();
end;
Даем конструкции новую мессагу m4 и приехали... Кот работает как ни в чем не бывало. И только по побочным эффектам от багов можно будет догадаться, что забыл добавить обработку этой новой мессаги.
Обероновская шина сообщений по такому принципу и работает -- кто понял сообщение, то его принял и обработал, а кто не понял -- игнорирует. А иначе при добавлении каждого нового сообщения придётся переделывать, а затем и перекомпилировать все модули, использующие эту шину сообщений, а это противоречит самим принципам оберон-систем...
-
Что за "Обероновская шина сообщений"?
Есть конкретные практические задачи в которых обработчик сообщений обязан знать все типы сообщений. В таких задачах нужен HALT.
И есть, да, другие задачи где обработчик должен знать только часть типов, а остальные пропускать дальше по шине. Вот на этот случай нужен ELSE, т.е. мы явно указываем поведение обработчика.
-
Что за "Обероновская шина сообщений"?
"generic message bus" же
-
"message bus" оно и в Африке "message bus"
"generic" или не "generic" - в данном случае значения не имеет.
-
Есть конкретные практические задачи в которых обработчик сообщений обязан знать все типы сообщений. В таких задачах нужен HALT.
Нет у Вирта таких задач. Вопрос закрыт :)
-
Видимо да. :D