Is there a SHOULD (or other modal verb) constructs in any programming languages?

Question

As far as I know I've never encountered a SHOULD construct in a computer language, but then again I don't know that many languages, compared to the hundreds out there.

Anyways SHOULD and other modal verbs are very common in natural languages, and their meanings are quite clear when writing documentation and legal-binding contracts, so they aren't really gray terms, and theoretically could be expressed in programming terms (I guess).

For example an ASSERT, upholds in a sense a MUST construct.

Are there any actual examples of this sort of thing? Any research about it? I'm guessing some Rule-Based systems, and perhaps fuzzy logic algorithms work like this.

Answer 1

I think of try as "should" and catch and finally as "in case it doesn't"

Answer 2

The exact meaning of should in natural language is also not clear cut. When you say "the wheel should fit in the row" - what does that mean exactly? It may mean the same as must, but then there is no point in a construct for it. Else, at what confidence do you need to be for this to be satisfied? What is the action in case the wheel does not fit?

In the senses you referred to, there are some equivalents, though I do not know of language that use the word should for them:

Testing/assertion

ASSERT is often a language directive, macro, or testing library function. In the sense that ASSERT corresponds to must, some languages and testing frameworks define macros for "warning assertions" which will spit a warning message if the check fails but not bail out or fail the test - that would correspond to should.

Exception handling

In some terms, you can consider exception thrown as analogues - if an exception is caught, the program can handle the case where something is not as it should be. But sometimes the exception describes the failure of something to be as it must be for the program to work, in which case the exception will not be caught or the handler will make the program fail gracefully. This is however not always the case - sometimes code is executed to test something that may be or perhaps is even unlikely to be, and an exception is caught expecting that it will usually be thrown.

Constraint logic

One common meaning of must and should in various formal natural language documents is in terms of constraints - must specifying a constraint that you always have to satisfy, and if you cannot then your state is incompatible, while should means that you will always satisfy the constraint if it is possible given the state and the constraints implied by must, but if it is not possible that is still valid. In informal constraint logic, this occurs when there are "external constraints" in the context - so verifying that the "solution" is satisfactory with respect to the "should constraints" may be possible only with knowledge of the context, and given the context you may also be able to satisfy different subsets of the "should constraints" but not at the same time. For that reason, some constraint logic specification languages (whether you call them "programming languages" depends on your definition) have the concepts of ordering of constraints - the first level of constraints corresponds to must, the next level corresponds to should, and a constraint has to be satisfied if possible given all constraints external to it (in previous levels), even if that conflicts with some constraints in the next levels which will then not be satisfied.