Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ternary is not Kleene #2958

Merged
merged 3 commits into from Oct 29, 2021
Merged

Conversation

henrikt-ma
Copy link
Collaborator

This PR is meant to be the continuation of the discussion in the main MCP issue, with last comment #2477 (comment).

The goal is to remove traces of Ternary being designed as a model of Kleene logic, and make it clear that Ternary doesn't want to be any other particular ternary logic either.

Note that this PR is only targeting the design documents, and is meant to be merged before work on actual specification changes is initiated. This allows us to have this discussion now, instead of delaying it until proposed specification changes are available.

This puts emphasis on Ternary not being designed to be a complete model of Kleene logic -- the truth tables for 'not', 'and' and 'or' are just defined in accordance with Kleene.
@henrikt-ma henrikt-ma added MCP0034 Ternary (MCP-0034) MCP Generic MCP label (prefer specific MCP label for grouping of issues belonging to the same MCP) labels Jun 21, 2021
@henrikt-ma henrikt-ma mentioned this pull request Jun 21, 2021

For example, to evaluate `false or unknown`, one has to consider both possible outcomes for the uncertain operand, meaning that the result might be ither `false or false` or `false or true`. Since the different outcomes don't agree, the result of the operation is uncertain, represented by `unknown`.

Although the truth tables of `not`, `and` and `or` agree with Kleene logic, the set of logical connectives on `Ternary` is deliberately not meant to model any particular ternary logic. In particular, by not defining an operator for material implication, `Ternary` cannot be considered a complete model of Kleene logic. Applications requiring a complete model of one of the many possible ways to define ternary logic may use `Ternary` to represent the three truth values, but should define all the logical connectives of the logic in question as a package (library) of functions.
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This paragraph relates to this comment in the main MCP issue:

To reassure you that the MCP is not about a 3-valued logic as you think of it, note that the MCP does not introduce an implies operator

The Kleene truth tables of the MCP already define implication (since implication in Kleene is just ¬A ∨ B). The issues of this logic are there, regardless if we support a dedicated implication operator or not. The point of these issues I described above is not that Kleene is wrong or something. The issue is that complex expressions in that logic often yield very surprising results (for which reason other, more advanced logics are proposed). More complex 3-valued logic relations may be hard to develop and likely boil down to try and error for users or need for step-by-step debugging of logic expressions.

So, while I agree that implication in Kleene is ¬A ∨ B, I wouldn't call something Kleene logic until this definition has been made.


For example, to evaluate `false or unknown`, one has to consider both possible outcomes for the uncertain operand, meaning that the result might be ither `false or false` or `false or true`. Since the different outcomes don't agree, the result of the operation is uncertain, represented by `unknown`.

Although the truth tables of `not`, `and` and `or` agree with Kleene logic, the set of logical connectives on `Ternary` is deliberately not meant to model any particular ternary logic. In particular, by not defining an operator for material implication, `Ternary` cannot be considered a complete model of Kleene logic. Applications requiring a complete model of one of the many possible ways to define ternary logic may use `Ternary` to represent the three truth values, but should define all the logical connectives of the logic in question as a package (library) of functions.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Attaching comment to empty line just to get a separate discussion thread.) The paragraph, meant to turn into non-normative text in the specification also tries to address this concern from the main MCP issue:

the MCP does not intend to enter the muddy waters of all 3-valued logics

And I don't want it to be the opener for future proposals in that direction.

If we say: That's it, Kleene truth tables and nothing more -- even if hell freezes -- I am very much Ok with it. The Kleene 3-valued logic is the most simple straight forward many-valued logic. I consider it very limited in its application area however -- that is why it is not used for anything but most simple applications. If somebody comes in the future with "but that case of the three-valued logic also needs some consideration" we should pull the plug.

I believe it will be hard to specify things in a way that will for sure prevent more or less arbitrary future specialization to some popular ternary logic, but I think that a well formulated non-normative paragraph or two should be able to capture the essence of the concerns felt today, and thereby drastically reduce risk of these concerns being forgotten or ignored in the future.

@@ -32,10 +32,12 @@ There is a total order of the possible `Ternary` values given by `Ternary(false)

## Expressions with Ternary

Logical operations on `Ternary` are defined according to Kleene, where `unknown` can be thought of as representinc uncertainty about being `true` or `false`. With this interpretation the Kleene logic tables then follow from the Boolean logic.
The logical connectives `not`, `and` and `or` on `Ternary` are defined in accordance with Kleene, where `unknown` can be thought of as representinc uncertainty about being `true` or `false`. With this interpretation the truth tables then follow from the Boolean logic.
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Regarding comment in main MCP issue:

Right. We should not use Ternary to build theorem proofers.

But our users will see the 3-valued logic, and start trying it on more complex domains than just dialog visibility. I have this requirements engineering library of EDF in my mind that had been proposed some time ago, also as a motivation to add 3-valued logic (at the end it turned out it was kind of a 4-valued logic because of the need to model time ... voilà, there it goes). With the proposed 3-valued logic, this requirements engineering example will first become sort-of more easy to develop, but then turns out to fall short and then all the craziness comes in step by step as additional requirements and corner-cases.

Your comment makes me think of the connectives I would have liked to handle things like "Boolean annotations with clever automatic default". Instead of interpreting unknown as unknown, I would have liked it to be interpreted as disregard, allowing it to be cancelled from both conjunction and disjunction. That is, instead of and and or, I would have wanted the connectives duand (disregard-unknown-and) and duor (disregard-unknown-and). Do you happen to know if this has a name in the literature? If so, maybe this could also be mentioned non-normatively, as it illustrates that not even the truth tables for and and or are as obvious as one might first think?

@henrikt-ma
Copy link
Collaborator Author

@christoff-buerger I think that the contents of this PR have been assumed already part of the current proposal when discussed at the previous web meeting. Would you agree, meaning that we should merge this to again have everything in one place?

@christoff-buerger christoff-buerger merged commit b62a65f into MCP/0034 Oct 29, 2021
@christoff-buerger christoff-buerger deleted the MCP/0034+ternary-is-not-kleene branch October 29, 2021 20:41
@christoff-buerger
Copy link
Member

@christoff-buerger I think that the contents of this PR have been assumed already part of the current proposal when discussed at the previous web meeting. Would you agree, meaning that we should merge this to again have everything in one place?

I am sorry for the late reply.
Yes, I agree.
I just merged the request.

@beutlich beutlich removed the request for review from christoff-buerger October 30, 2021 08:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
MCP Generic MCP label (prefer specific MCP label for grouping of issues belonging to the same MCP) MCP0034 Ternary (MCP-0034)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants