Есть ли ОБЯЗАТЕЛЬНЫЕ (или другие модальные глаголы) конструкции в каких-либо языках программирования?

Question

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

В любом случае СЛЕДУЕТ и другие модальные глаголы очень распространены в естественных языках, и их значения достаточно ясны при написании документации и юридически обязывающих контрактов, поэтому они не совсем серые термины и теоретически могут выражается в программировании (я думаю).

Например, ASSERT поддерживает в некотором смысле конструкцию MUST .

Есть ли реальные примеры такого рода вещей? Любое исследование об этом? Я предполагаю, что некоторые системы, основанные на правилах, и, возможно, алгоритмы нечеткой логики работают следующим образом.

Answer 1

Я думаю о try как "следует" и catch и finally как "в случае, если это не так"

Answer 2

Точное значение следует на естественном языке также не ясно выражено. Когда вы говорите «колесо должно поместиться в ряд» - что это значит? Это может означать то же самое, что must , но тогда в конструкции нет никакого смысла. Иначе, с какой уверенностью вы должны быть для этого, чтобы быть удовлетворенным? Что делать, если колесо не подходит?

В упомянутых вами смыслах есть некоторые эквиваленты, хотя я не знаю языка, в котором слово должно означать для них:

Тестирование / утверждение

ASSERT часто является директивой языка, макросом или функцией библиотеки тестирования. В том смысле, что ASSERT соответствует must , некоторые языки и платформы тестирования определяют макросы для «предупреждений о предупреждении», которые будут выдавать предупреждающее сообщение, если проверка не пройдена, но не выручит или не провалит тест - это будет соответствует должен .

Обработка исключений

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

Ограничительная логика

Одно общее значение must и must в различных официальных документах на естественном языке заключается в ограничениях - must указывает ограничение, которое вы всегда должны удовлетворять и если вы не можете, то ваше состояние несовместимо, в то время как должен означает, что вы всегда будете удовлетворять ограничению , если это возможно , учитывая состояние и ограничения, подразумеваемые must , но , если это невозможно , который все еще действителен. В неформальной логике ограничений это происходит, когда в контексте существуют «внешние ограничения», поэтому проверка того, что «решение» является удовлетворительным по отношению к « должны ограничения», может быть возможна только при знании контекста. и с учетом контекста вы также можете удовлетворить различные подмножества ограничений « should », но не одновременно. По этой причине некоторые языки спецификации логики ограничений (называете ли вы их «языками программирования», зависит от вашего определения) имеют понятия упорядочения ограничений - первый уровень ограничений соответствует must , следующий уровень соответствует до должно , и ограничение должно быть выполнено, если возможно, с учетом всех внешних для него ограничений (на предыдущих уровнях), даже если это противоречит некоторым ограничениям на следующих уровнях, которые затем не будут выполнены.

Answer 3

Модальные глаголы типа «следует», «может», «может» могут вызвать путаницу, поэтому RFC 2119 дает определение для направления всех носов в одном направлении:

SHOULD   This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.

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

Answer 4

Этот вид модальности используется в RSpec - dsl для построения тестов в стиле поведения.

Answer 5

@ Саймон Возможно, попытка / наконец-то ближе всего к тому, что следует. все в Try должно работать, но не всегда. Веб-сервис должен открыть сокет, но если этого не произойдет, нам все равно.

Answer 6

Какое поведение вы ожидаете от программы, если результат не такой, как ДОЛЖЕН? В случае ASSERT это исключение (AssertException или подобное). Должна ли программа генерировать исключение или просто игнорировать результат? Мне кажется, что между ними нет ничего. Либо результат принят, либо нет.

В противном случае вы ДОЛЖНЫ указать, какое поведение вы ожидаете. : -)

Вернуться к утверждению: если утверждение не выполнено, выдается исключение. Вам решать, что вы делаете с этим исключением. В java / C #, например, вы можете поймать его и затем делать все, что захотите, поэтому вы определяете, имеет ли assert семантическую НЕОБХОДИМОСТЬ или СЛЕДУЕТ.

Answer 7

Хорошо. Может ли быть найден язык пролога, как более мягкий вывод? Т.е. логически результат должен быть x, но может и не быть. Вы можете сказать, что результат, вероятно, х, но не однозначно?

Answer 8

Ну, Java2K имеет аналогичные понятия. ДОЛЖНО делать то, что ему говорят ...

SCNR.