私の知る限り、コンピューター言語でSHOULD構造に遭遇したことはありませんが、数百の言語と比較して、その多くの言語を知ることはできません。
とにかく、 SHOULDやその他の法助動詞は自然言語では非常に一般的であり、ドキュメントや法的拘束力のある契約を書くときの意味は非常に明確であるため、実際には灰色の用語ではなく、理論的にはプログラミング用語で表現できます（私は推測します）。
たとえば、ASSERTは、ある意味でMUST構造を支持します。
このようなことの実際の例はありますか？それについて何か研究はありますか？私はいくつかのルールベースのシステムを推測しています、そしておそらくファジー論理アルゴリズムはこのように機能します。
私はtry「すべき」とcatch「finallyそうでない場合」と考えています
自然言語でのshouldの正確な意味も明確ではありません。「ホイールは列に収まる必要があります」と言うとき、それは正確にはどういう意味ですか? mustと同じ意味かもしれませんが、その場合、構文には意味がありません。そうでなければ、これが満たされるためには、どの程度の自信が必要ですか? ホイールが合わない場合の対処法は？
あなたが言及した意味では、いくつかの同等物がありますが、それらに相当する単語を使用する言語を私は知りません:
ASSERT多くの場合、言語ディレクティブ、マクロ、またはテスト ライブラリ関数です。mustASSERTに対応する意味で、一部の言語とテスト フレームワークは、チェックが失敗した場合に警告メッセージを吐き出す「警告アサーション」用のマクロを定義しますが、テストを回避または失敗することはありません。これは should に対応します。
ある意味では、スローされた例外を類似物と見なすことができます。例外がキャッチされた場合、プログラムは何かが本来あるべきものではないケースを処理できます。ただし、例外は、プログラムが機能するためには何かの失敗を説明する場合があります。その場合、例外はキャッチされないか、ハンドラーがプログラムを正常に失敗させます。ただし、常にそうであるとは限りません。場合によっては、コードが実行されて、可能性があるか、可能性が低いものをテストし、通常はスローされることを予期して例外がキャッチされます。
さまざまな正式な自然言語ドキュメントでのmustとshouldの一般的な意味の 1 つは、制約に関するものです。must は、常に満たさなければならない制約を指定します。満たされない場合、状態は互換性がありません。一方、shouldは、常に制約を満たすことを意味します。状態とmustによって暗示される制約が与えられた場合は可能ですが、不可能な場合でも有効です。非公式の制約ロジックでは、これは文脈に「外部制約」がある場合に発生します。制約」は、コンテキストの知識がある場合にのみ可能である可能性があり、コンテキストが与えられると、「必要な制約」のさまざまなサブセットも満たすことができますが、同時に満たすことはできません。そのため、一部の制約ロジック仕様言語 (それらを「プログラミング言語」と呼びますが、定義によって異なります) 制約の順序付けの概念があります - 制約の最初のレベルはmustに対応し、次のレベルはshouldに対応し、可能な場合、制約はその外部のすべての制約が与えられた場合に満たされる必要があります(以前のレベルでは)、それが次のレベルのいくつかの制約と競合する場合でも、それは満たされません。
この種のモダリティは、RSpec -dslで、動作駆動型のテストを構築するために使用されます。
@Simon おそらく、Try/finally が最も近いはずです。Try 内のすべてが実行されますが、常に実行されるとは限りません。Web サービスはソケットを開く必要がありますが、開いていなくてもかまいません。
「should」、「may」、「might」などのモーダル動詞は混乱を招く可能性があるため、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.
この定義から、プログラムコードではなく、決定論的なものが必要な仕様で使用されることを意図していることは明らかです。少なくとも私はそうします。でも、AIで使えることは想像できます。
さて、よりソフトな推論として、プロローグタイプの言語で見つかるかもしれませんか？つまり、結果は論理的にxである必要がありますが、そうではない可能性があります。結果はおそらくxであると言えますが、明確ではありませんか？
結果が本来あるべきものではない場合、プログラムに期待する動作は何ですか？ASSERTの場合、これは例外です（AssertExceptionなど）。プログラムは例外をスローするべきですか、それとも結果を無視するべきですか？私には、その間に何もないように思えます。結果が受け入れられるかどうか。
それ以外の場合は、期待する動作を指定する必要があります。:-)
アサーションに戻る：アサーションが失敗すると、例外がスローされます。その例外を除いて何をするかはあなた次第です。たとえば、java / C＃では、それをキャッチして、必要なことを何でも実行できるため、アサーションにMUSTまたはSHOULDセマンティクスがあるかどうかを定義します。
Java2Kにも同様の概念があります。言われたことを実行する必要があります...
SCNR。