据我所知，我从未在计算机语言中遇到过 SHOULD 构造，但与那里的数百种语言相比，我再也不知道那么多语言。
无论如何应该和其他模态动词在自然语言中非常常见，在编写文档和具有法律约束力的合同时它们的含义非常清楚，所以它们并不是真正的灰色术语，理论上可以以编程术语表达（我猜）。
例如 ASSERT ，在某种意义上支持 MUST 构造。
有这种事情的实际例子吗？关于它的任何研究？ 我猜测一些基于规则的系统，也许模糊逻辑算法就像这样工作。
答案 0 :(得分：6)
我认为try为“应该”而catch和finally为“如果不是”
答案 1 :(得分：4)
自然语言 的确切含义也不明确。当你说“轮子应适合行”时 - 这究竟意味着什么？它可能与必须相同，但在构造中没有任何意义。另外，你需要有什么信心才能满足这个要求？如果车轮不适合，动作是什么？
在您提到的意义上，有一些等价物，但我不知道使用应该这个词的语言：
ASSERT通常是语言指令，宏或测试库函数。在ASSERT对应必须的意义上，某些语言和测试框架定义了“警告断言”的宏，如果检查失败但不会挽救或未通过测试，它将发出警告消息 - 这对应于应该。
在某些方面，您可以将异常抛出为类似物 - 如果捕获到异常，程序可以处理某些内容不是应该的情况。但有时候异常会描述某些事情的失败，因为必须让程序工作，在这种情况下，不会捕获异常，或者处理程序会使程序正常失败。但情况并非总是如此 - 有时会执行代码来测试可能或甚至不太可能的内容，并且会发现一个异常，期望它通常会被抛出。
在各种形式的自然语言文档中，必须和应该的一个常见含义是约束 - 必须指定一个总是你的约束必须满足，如果你不能，那么你的状态是不兼容的，而应该意味着你总是满足约束如果可能的话给定状态和隐含的约束必须，但如果不可能仍然有效。在非正式约束逻辑中，当上下文中存在“外部约束”时会发生这种情况 - 因此只有知道“ 约束”才能验证“解决方案”是否令人满意。上下文，并且给定上下文，您也可以满足“ should 约束”的不同子集，但不能同时满足。出于这个原因，一些约束逻辑规范语言（无论你称之为“编程语言”取决于你的定义）都有约束排序的概念 - 第一级约束对应必须，下一级对应于应该，并且如果可能的话，必须满足约束条件（在先前的级别中），即使它与下一级别中的某些约束冲突，否则将不满足约束。
答案 2 :(得分：2)
@Simon也许一个Try / finally最接近应该。 Try中的任何内容都应该运行，但并非总是如此。 Web服务应该打开socket，但如果没有，我们就不在乎了。
答案 3 :(得分：2)
这种模态在RSpec - dsl中用于以行为驱动的方式构建测试。
答案 4 :(得分：2)
“应该”，“可能”，“可能”等模态动词可能会造成混淆，因此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中可用。
答案 5 :(得分：1)
那么应该在prolog类型的语言中找到更柔和的推理吗？即结果逻辑上应该是x但可能不是。你可以说结果可能是x但不是明确的吗？
答案 6 :(得分：1)
如果结果不是这样，你对程序的期望是什么？在ASSERT情况下，它是一个异常（AssertException或类似的）。该程序应该抛出异常还是忽略结果？对我而言，似乎两者之间没有任何东西。结果是否被接受。
否则你应该指定你期望的行为。 ： - ）
回到断言：如果断言失败，则抛出异常。这取决于您对该例外的处理方式。在java / C＃中，例如，您可以捕获它然后执行任何您想要的操作，因此您可以定义断言是否具有MUST或SHOULD语义。
答案 7 :(得分：0)
嗯，Java2K有类似的概念。它应该做它所说的......
SCNR。