Ternary is not Kleene

RationaleMCP/0034/ReadMe.md

@@ -35,7 +35,7 @@ A prototype has been implemented in a development version of Wolfram SystemModel
 ### Experience with Prototype
 Although introducing a new built-in type is a change that ammounts to a large number of smaller changes, finding the places in a code base that need attention is easy due to the similarity between `Ternary` and `Boolean`.  In a similar way, the implicit conversion from `Boolean` to `Ternary` is a feature that can be implemented by glancing at the handling of implicit conversion from `Integer` to `Real`.
 
-Regarding the application of this MCP to a new attribute called `visible` in the `Dialog` annotation, the proposed choice of Kleene logic certainly gets the job done.  The default value of `unknown` which means _apply tool-specific rules for visibility_, a user can easily write a ternary logical expression to override the default in either way, and the expression may also evaluate to `unknown` in cases where the user doesn't want to fall back on the tool logic.  Thanks to the implicit cast from `Boolean`, most uses of `visible` would probably be in the simple forms `visible = true` or `visible = false`.  However, upon closer acquaintance with the Kleene logic, which still appears as the most natural choice for `Ternary`, it has been questioned whether this is the best way to model the absence of information, see [rationale](rationale.md#The-option-type-alternative).
+Regarding the application of this MCP to a new attribute called `visible` in the `Dialog` annotation, the proposed choice of defining `not`, `and` and `or` in accordance with Kleene logic certainly gets the job done.  The default value of `unknown` which means _apply tool-specific rules for visibility_, a user can easily write a ternary logical expression to override the default in either way, and the expression may also evaluate to `unknown` in cases where the user doesn't want to fall back on the tool logic.  Thanks to the implicit cast from `Boolean`, most uses of `visible` would probably be in the simple forms `visible = true` or `visible = false`.  However, upon closer acquaintance with the Kleene logic – which still appears as the most natural basis for defining the logical connectives for `Ternary` – it has been questioned whether this is the best way to model the absence of information, see [rationale](rationale.md#The-option-type-alternative).
 
 ## Required Patents
 To the best of our knowledge, there are no patents that would conflict with the incorporation of this MCP.

RationaleMCP/0034/rationale.md

@@ -77,7 +77,7 @@ Even though the use of option types could be restricted to `Boolean` to start wi
 Another advantage of introducing option types instead of `Ternary` would be that it would probably be acceptable to say that no option type can be used for indexing into arrays.  This would simplify parts of the implementation compared to `Ternary`.
 
 However, these are some reasons for sticking with `Ternary` instead of `Boolean?`:
-- If the usual ternary logic according to Kleene is what we want — which is the assumption of this MCP — the use of `Boolean?` would imply an unnatural interpretation of `none`.  [This argument is elaborated below.](#Using-none-to-represent-undefined)
+- If the usual ternary operators `not`, `and` and `or` in accordance with Kleene is what we want — which is the assumption of this MCP — the use of `Boolean?` would imply an unnatural interpretation of `none`.  [This argument is elaborated below.](#Using-none-to-represent-undefined)
 - Introducing the literal `none` to refer to the absence of a value for an option type leads to a significant change of the Modelica type system, as `none` can have any option type.  Even if type inference would be implemented, there would be problems when it comes to implicit conversions (see above).
 - Explicitly writting out the type of a _none_ as in `Boolean?()` would be inconvenient compared to just saying `unknown`.  (However, it would then be natural to define implicit conversion to any option type.)
 - Attributes of other type than `Boolean` typically have a default behavior that can be expressed with a default value (like the empty string in case of `String`), removing the need for an option type to express the absence of a value.
@@ -87,7 +87,7 @@ However, these are some reasons for sticking with `Ternary` instead of `Boolean?
 - It is probably a bad idea to just introduce option types in Modelica without considering the more general concepts that would give option types as a special case.  Such more general constructs inspired by MetaModelica have been discussed at many design meetings without getting much traction.
 
 ## Using `none` to represent _undefined_
-While possible to interpret `Boolean?()` (hereafter referred to as `none` for brevity) as _unknown_ and define logical operation on `Boolean?` in the same way as for `Ternary` to get a Kleene logic, the generalization of this interpretation to other option types such as `Real?` or `String?` isn't as useful.  The natural interpretation of `none` would rather be _undefined_, which leads to more useful generalizations to other option types.
+While possible to interpret `Boolean?()` (hereafter referred to as `none` for brevity) as _unknown_ and define logical operation on `Boolean?` in the same way as for `Ternary` to get consistency with Kleene logic, the generalization of this interpretation to other option types such as `Real?` or `String?` isn't as useful.  The natural interpretation of `none` would rather be _undefined_, which leads to more useful generalizations to other option types.
 
 For example, one could define that concatenation with an _undefined_ `String?`, would be a no-op, and the same for addition or multiplication with an _undefined_ `Real?`.  For `Boolean?` it would then be natural to define both disjunction and conjunction with _undefined_ to be no-ops, leading to things such as `none and true = some(true)`.
 
@@ -104,4 +104,4 @@ Please note that this logical table does not correspond to the often cited four-
 
 For the numeric types `Real` and `Integer`, a better analog to `unknown` would be `NaN` (not-a-number), having very different arithmetic behavior compared to the no-ops of _undefined_.  For example, this gives the expected behavior of adding _unknown_ to any number resulting in _unknown_.
 
-To summarize, while option types have many interesting applications — including modeling of built-in attributes with non-trivial defaults — it would be a mistake to use `Boolean?` for the usual ternary logic according to Kleene with _unknown_ as the third truth value.  This also shows that `Ternary` is not going to become redundant if option types are added to Modelica in the future.
+To summarize, while option types have many interesting applications — including modeling of built-in attributes with non-trivial defaults — it would be a mistake to use `Boolean?` for the usual ternary connectives defined in accordance with Kleene.  This also shows that `Ternary` is not going to become redundant if option types are added to Modelica in the future.

RationaleMCP/0034/ternary.md

@@ -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.
 
 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.
+
 ### Unary operators
 Unary operators on `Ternary`, where `x` is an expression of type `Ternary`: