looking for a predicate hierarchy

I am looking for a library (of an OO language) which uses a hierarchy of
classes for predicate (type) dispatch in the context of multimethod. Ce
concept is already well know and developed in the literature, but
languages which support multimethods and metaclasses are not so common.
Therefore, I have some difficulty to find such 'standard' use of class
as predicates. The papers usually use hierarchies inspired from specific
taxonomy (e.g. animals) which are not general enough to be useful.

For the moment in my lib I have (<- means 'inherits from'):

Predicate (root class)
<- Nil
<- TrueFalse
<- True
<- False
<- Ordered
<- Lesser
<- Equal
<- Greater

But there is a lot of other possible predicates (not all useful):

Next, Previous
Forward, Backward
Open, Close
Front, Rear
Bottom, Top
Before, After
Up, Down
Even, Odd
Left, Right
North, South, Est, West

etc...

and selecting the predicates general enough (aliases and user defined
predicates are always possible as extension) is somehow a problem of
experience. BTW, the hierarchy stigmatize the possible logical
combinations of the predicates (not, and, or) and strengthens the
importance of its design (e.g. TrueFalse != Boolean).

Has somebody already seen such hierarchy? Links and references would be
really appreciated. Thanks.

a+, ld.

On Mon, 18 Dec 2006 13:54:40 +0100, Laurent Deniau wrote:

> I am looking for a library (of an OO language) which uses a hierarchy of
> classes for predicate (type) dispatch in the context of multimethod. Ce
> concept is already well know and developed in the literature, but
> languages which support multimethods and metaclasses are not so common.
> Therefore, I have some difficulty to find such 'standard' use of class
> as predicates. The papers usually use hierarchies inspired from specific
> taxonomy (e.g. animals) which are not general enough to be useful.
>
> For the moment in my lib I have (<- means 'inherits from'):
>
> Predicate (root class)
> <- Nil
> <- TrueFalse
> <- True
> <- False
> <- Ordered
> <- Lesser
> <- Equal
> <- Greater
>
> But there is a lot of other possible predicates (not all useful):
>
> Next, Previous
> Forward, Backward
> Open, Close
> Front, Rear
> Bottom, Top
> Before, After
> Up, Down
> Even, Odd
> Left, Right
> North, South, Est, West
>
> etc...
>
> and selecting the predicates general enough (aliases and user defined
> predicates are always possible as extension) is somehow a problem of
> experience. BTW, the hierarchy stigmatize the possible logical
> combinations of the predicates (not, and, or) and strengthens the
> importance of its design (e.g. TrueFalse != Boolean).
>
> Has somebody already seen such hierarchy? Links and references would be
> really appreciated. Thanks.

It is group theory which describes such relations, like symmetry groups in
geometry, for example.

However, you will never be able to create such a hierarchy. The list you
proved is full of apples and oranges. True and False are elements of a
lattice. I presume you meant identity relation? Lesser, Equal, Greater are
binary relations. Ordered sets are not necessary lattices, even less
predicates. Vector spaces (where the relations like up and down could be
defined) aren't either. The set of all possible binary relations defined on
such structures cannot be ordered or arranged in a tree. Because already
the structures like 3D space (R^3) would be too rich for that. Even more
the set of all possible binary relations over it should be. Which is the
set of all possible sets of ordered pairs (x, y), i.e. 2^(R^6).

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Laurent Deniau wrote:
> I am looking for a library (of an OO language) which uses a hierarchy of
> classes for predicate (type) dispatch in the context of multimethod. Ce
> concept is already well know and developed in the literature, but
> languages which support multimethods and metaclasses are not so common.
> Therefore, I have some difficulty to find such 'standard' use of class
> as predicates. The papers usually use hierarchies inspired from specific
> taxonomy (e.g. animals) which are not general enough to be useful.
>
> For the moment in my lib I have (<- means 'inherits from'):
>
> Predicate (root class)
> <- Nil
> <- TrueFalse
> <- True
> <- False
> <- Ordered
> <- Lesser
> <- Equal
> <- Greater
>
> But there is a lot of other possible predicates (not all useful):
>
> Next, Previous
> Forward, Backward
> Open, Close
> Front, Rear
> Bottom, Top
> Before, After
> Up, Down
> Even, Odd
> Left, Right
> North, South, Est, West
>
> etc...
>
> and selecting the predicates general enough (aliases and user defined
> predicates are always possible as extension) is somehow a problem of
> experience. BTW, the hierarchy stigmatize the possible logical
> combinations of the predicates (not, and, or) and strengthens the
> importance of its design (e.g. TrueFalse != Boolean).
>
> Has somebody already seen such hierarchy? Links and references would be
> really appreciated. Thanks.

What do you mean by "predicate"? Is it logical concept? Then we can
talk about relations in the database theory sence, both finite and
infinite. Relations do form a lattice, so you work out tthis idea into
extracting a "hierarchy" out of the lattice. But is this really what
you want to do?

aloha.kakuikanu wrote:
> Laurent Deniau wrote:
>
>>I am looking for a library (of an OO language) which uses a hierarchy of
>>classes for predicate (type) dispatch in the context of multimethod. Ce
>>concept is already well know and developed in the literature, but
>>languages which support multimethods and metaclasses are not so common.
>>Therefore, I have some difficulty to find such 'standard' use of class
>>as predicates. The papers usually use hierarchies inspired from specific
>>taxonomy (e.g. animals) which are not general enough to be useful.
>>
>>For the moment in my lib I have (<- means 'inherits from'):
>>
>>Predicate (root class)
>> <- Nil
>> <- TrueFalse
>> <- True
>> <- False
>> <- Ordered
>> <- Lesser
>> <- Equal
>> <- Greater
>>
>>But there is a lot of other possible predicates (not all useful):
>>
>>Next, Previous
>>Forward, Backward
>>Open, Close
>>Front, Rear
>>Bottom, Top
>>Before, After
>>Up, Down
>>Even, Odd
>>Left, Right
>>North, South, Est, West
>>
>>etc...
>>
>>and selecting the predicates general enough (aliases and user defined
>>predicates are always possible as extension) is somehow a problem of
>>experience. BTW, the hierarchy stigmatize the possible logical
>>combinations of the predicates (not, and, or) and strengthens the
>>importance of its design (e.g. TrueFalse != Boolean).
>>
>>Has somebody already seen such hierarchy? Links and references would be
>>really appreciated. Thanks.
>
>
> What do you mean by "predicate"? Is it logical concept?

I am talking about class/type predicate in the context of mutlimethod
dispatch. For example, a binary method with True as its type
specialisation for its second formal argument answer positively if the
second argument on the caller side *is of class* True (or a subclass of
True).

class predicate dispatch is a subset of predicate dispatch which does
not include dispatch on boolean expression.

> Then we can
> talk about relations in the database theory sence, both finite and
> infinite. Relations do form a lattice, so you work out tthis idea into
> extracting a "hierarchy" out of the lattice. But is this really what
> you want to do?

Maybe ;-)

In fact multimethod implement natively the logical AND while inheritance
implement natively the logical OR between types/classes. State exclusion
is represented by different branches in the hierarchy.

Considering the first case (TrueFalse):

- TrueFalse is the indeterminate/uncertain state (also called the third
state in tribool and noted '?')
- True and False are (exclusive) specialization of TrueFalse by inheritance.
- Specialisation can be used to perform state complement (logical NOT)
because most specific specialisation are selected first.

With these observations, it is easy to build logical tables with the 3
states by writing 4 specialisations (instead of 9). For example, AND is
(sample of my code):

/*

AND | F | T | ?
----+---+---+---
F | F | F | F
T | F | T | ?
? | F | ? | ?

*/

defmethod(OBJ, And, (False,TrueFalse))
retmethod(False);
endmethod

defmethod(OBJ, And, (TrueFalse,False))
retmethod(False);
endmethod

defmethod(OBJ, And, (TrueFalse,TrueFalse))
retmethod(TrueFalse);
endmethod

defmethod(OBJ, And, (True,True))
retmethod(True);
endmethod

Note that because of inheritance and specialization, this hierarchy is
still valid if you restrict the allowed states only to True and False.

The same can be done for Ordered, which could also be understood as
Unordered depending on the existing specialisations. The advantage is
that the hierarchy above can represent the relation:

no order: specialisation on Ordered (as 'Unordered') only
total order: specialisation on Lesser, Equal and Greater only
partial order: idem total order plus specialisation on Ordered

So the same hierarchy can be applied to many cases where the defined
multimethods (the hierarchy is fixed) caracterise the allowed relation.

a+, ld.

On Tue, 19 Dec 2006 14:49:07 +0100, Laurent Deniau wrote:

> aloha.kakuikanu wrote:

>> What do you mean by "predicate"? Is it logical concept?
>
> I am talking about class/type predicate in the context of mutlimethod
> dispatch. For example, a binary method with True as its type
> specialisation for its second formal argument answer positively if the
> second argument on the caller side *is of class* True (or a subclass of
> True).

Do you mean <: relation here?

> class predicate dispatch is a subset of predicate dispatch which does
> not include dispatch on boolean expression.

What does "dispatch on Boolean expression mean?" Dispatch happens on a
tuple of polymorphic objects. For example, AND dispatches on the tuple (1st
argument, 2nd argument, result).

>> Then we can
>> talk about relations in the database theory sence, both finite and
>> infinite. Relations do form a lattice, so you work out tthis idea into
>> extracting a "hierarchy" out of the lattice. But is this really what
>> you want to do?
>
> Maybe ;-)
>
> In fact multimethod implement natively the logical AND while inheritance
> implement natively the logical OR between types/classes.

It is difficult to understand why. Anyway, logical operations on types as
sets of values produce new types. If we'd considered the domain sets of
types as a lattice, we could consider AND, OR, NOT operations there. I
don't think that might get us anywhere far, because the type systems of
programming language are not enough strong to be able to describe all
elements of such lattice. Consider NOT Integer. This would be a quite
non-constructive thing. What are non-integers? What are the operations of?
The second question is even more tricky. Let I do String OR Customer. What
happens with *?

> State exclusion
> is represented by different branches in the hierarchy.
>
> Considering the first case (TrueFalse):
>
> - TrueFalse is the indeterminate/uncertain state (also called the third
> state in tribool and noted '?')

(in logic "uncertain" is usually denoted as _|_, flipped T)

> - True and False are (exclusive) specialization of TrueFalse by inheritance.
> - Specialisation can be used to perform state complement (logical NOT)
> because most specific specialisation are selected first.
>
> With these observations, it is easy to build logical tables with the 3
> states by writing 4 specialisations (instead of 9).

Hmm, it should be 8.

= 2^3

2 = the depth of the type hierarchy
3 = the number of parameters within the same hierarchy (2 arguments + the
result)

When Boolean and TriState are related types and both arguments and the
result of AND are covariant then the dispatching table of AND will have 8
slots:

AND : Boolean x Boolean -> Boolean
AND : Boolean x Boolean -> TriState
AND : Boolean x TriState -> Boolean
AND : Boolean x TriState -> TriState
AND : TriState x Boolean -> Boolean
AND : TriState x Boolean -> TriState
AND : TriState x TriState -> Boolean
AND : TriState x TriState -> TriState

Taking into account commutativity of AND, the number of distinct signatures
can be reduced to 6:

AND : Boolean x Boolean -> Boolean
AND : Boolean x Boolean -> TriState
AND : Boolean x TriState -> Boolean
== AND : TriState x Boolean -> Boolean
AND : Boolean x TriState -> TriState
== AND : TriState x Boolean -> TriState
AND : TriState x TriState -> Boolean
AND : TriState x TriState -> TriState

Because TriState is a generalization of Boolean (or equivalently Boolean is
a specialization of TriState)

AND : Boolean x Boolean -> Boolean
<= AND : Boolean x Boolean -> TriState
AND : Boolean x TriState -> Boolean
== AND : TriState x Boolean -> Boolean
AND : Boolean x TriState -> TriState
== AND : TriState x Boolean -> TriState
AND : TriState x TriState -> TriState
=> AND : TriState x TriState -> Boolean

> For example, AND is
> (sample of my code):
>
> /*
>
> AND | F | T | ?
> ----+---+---+---
> F | F | F | F
> T | F | T | ?
> ? | F | ? | ?
>
> */
> defmethod(OBJ, And, (False,TrueFalse))
> retmethod(False);
> endmethod
>
> defmethod(OBJ, And, (TrueFalse,False))
> retmethod(False);
> endmethod
>
> defmethod(OBJ, And, (TrueFalse,TrueFalse))
> retmethod(TrueFalse);
> endmethod
>
> defmethod(OBJ, And, (True,True))
> retmethod(True);
> endmethod
>
> Note that because of inheritance and specialization, this hierarchy is
> still valid if you restrict the allowed states only to True and False.
>
> The same can be done for Ordered, which could also be understood as
> Unordered depending on the existing specialisations. The advantage is
> that the hierarchy above can represent the relation:
>
> no order: specialisation on Ordered (as 'Unordered') only
> total order: specialisation on Lesser, Equal and Greater only
> partial order: idem total order plus specialisation on Ordered
>
> So the same hierarchy can be applied to many cases where the defined
> multimethods (the hierarchy is fixed) caracterise the allowed relation.

The algebraic properties of the dispatching table you observed for AND are
determined by:

1. Dispatching parameters = the arguments and results in which the method
is polymorphic = covariant of the involved parameters.

2. Symmetries along the parameters. Like commutativity (of +,*, AND etc),
group inverses (of - to +, / to *), De Morgan rules etc etc. For example,
relations as < possess symmetries like a<b <=> not b>=a. This also can
reduce the number of signatures. However, note that symmetries often get
violated upon inheritance. For example, should you extend R to a set of
square matrices over R, you would loose commutativity of *.

3. Properties of the domain sets of the involved types. Like existence of
injective mappings between the values (generalization). This is as crucial
as 2. When you extend R to C you loose order. When you extend R to
intervals, the order stays, but gets crippled. The result of < becomes
tri-state.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Laurent Deniau <laurent.deniau{}cern.ch> wrote in
news:em8qkq$iea$1{}cernne03.cern.ch:


> I am talking about class/type predicate in the context of mutlimethod
> dispatch. For example, a binary method with True as its type
> specialisation for its second formal argument answer positively if the
> second argument on the caller side *is of class* True (or a subclass
> of True).
>
> class predicate dispatch is a subset of predicate dispatch which does
> not include dispatch on boolean expression.

I can't make head or tail of that. A predicate is a string of characters
formed and manipulated according to the predicate logic rules without any
paticular meaning by itself. Its 'meaning' is usualy understood as a
certain relation.

> - TrueFalse is the indeterminate/uncertain state (also called the
> third state in tribool and noted '?')

WTF is 'tribool' ???

> - True and False are (exclusive) specialization of TrueFalse by
> inheritance. - Specialisation can be used to perform state complement
> (logical NOT) because most specific specialisation are selected first.
>
> With these observations, it is easy to build logical tables with the 3
> states by writing 4 specialisations (instead of 9). For example, AND
> is (sample of my code):
>
> /*
>
> AND | F | T | ?
> ----+---+---+---
> F | F | F | F
> T | F | T | ?
> ? | F | ? | ?
>
> */

What about implication in your system ?

Dmitry A. Kazakov wrote:
> On Tue, 19 Dec 2006 14:49:07 +0100, Laurent Deniau wrote:
>
>
>>aloha.kakuikanu wrote:
>
>
>>>What do you mean by "predicate"? Is it logical concept?
>>
>>I am talking about class/type predicate in the context of mutlimethod
>>dispatch. For example, a binary method with True as its type
>>specialisation for its second formal argument answer positively if the
>>second argument on the caller side *is of class* True (or a subclass of
>>True).
>
>
> Do you mean <: relation here?

yes.

>>class predicate dispatch is a subset of predicate dispatch which does
>>not include dispatch on boolean expression.
>
>
> What does "dispatch on Boolean expression mean?" Dispatch happens on a
> tuple of polymorphic objects.

Yes. But tuple dispatch is a restricted version of predicate dispatch
where dispatch happens on a tuple of polymorphic objects plus some
constraint expressed as a boolean expression on the values of the
instances. As an example:

person vote(p{}person) when age >= 18
// register vote
return p;

means that this vote specialization will be called if the type of its
first argument p is a person and if its age (a state variable of a
person) is >= 18.

in C++ it could be written as:

person& vote(person &p)
{
if (p.age >= 18) {
// register p
}

return p;
}

But this is a closed form (not extensible).

You can have a look to:

http://www.cs.ucla.edu/~todd/research/oopsla04.pdf

for more examples and code equivalence.

Internally, predicate dispatch is equivalent to evaluate the boolean
expression and call the specialization (generated by the compiler):

person vote(p{}person, true{}bool)
// register vote
return p;

which is just a tuple dispatch. See the work of Chambers

http://citeseer.ist.psu.edu/337093.html

for an efficient algorithm which transforms predicate dispatch into
tuple dispatch (as 1-uple dispatch) and implemented in Cecil and some
extension of Dylan.

> For example, AND dispatches on the tuple (1st
> argument, 2nd argument, result).
>
>
>>>Then we can
>>>talk about relations in the database theory sence, both finite and
>>>infinite. Relations do form a lattice, so you work out tthis idea into
>>>extracting a "hierarchy" out of the lattice. But is this really what
>>>you want to do?
>>
>>Maybe ;-)
>>
>>In fact multimethod implement natively the logical AND while inheritance
>>implement natively the logical OR between types/classes.
>
>
> It is difficult to understand why. Anyway, logical operations on types as
> sets of values produce new types.

I don't think so. Logical operations on types do not produce new types,
but select other type.

> If we'd considered the domain sets of
> types as a lattice, we could consider AND, OR, NOT operations there. I
> don't think that might get us anywhere far, because the type systems of
> programming language are not enough strong to be able to describe all
> elements of such lattice. Consider NOT Integer. This would be a quite
> non-constructive thing.

It is. Consider the following hierarchy

Number
<- Integer
<- Floating
<- Complex

If a specialization for Number exists, NOT Integer means Floating OR
Complex specialization. If you add a subclass to Number, then it is
automatically added to the set NOT Integer. This is why I said that
inheritance implement logical OR and specialization *may* implement
complement.

> What are non-integers? What are the operations of?
> The second question is even more tricky. Let I do String OR Customer. What
> happens with *?

?

>>State exclusion
>>is represented by different branches in the hierarchy.
>>
>>Considering the first case (TrueFalse):
>>
>>- TrueFalse is the indeterminate/uncertain state (also called the third
>>state in tribool and noted '?')
>
>
> (in logic "uncertain" is usually denoted as _|_, flipped T)

but it is not a valid token and it also means non-terminal, error, nil,
false, etc... So usually, libraries adopted indeterminate or uncertain
for this 'third' boolean state (i.e. tribool).

and I am not talking about predicate logic, but class for predicate
dispatch. The context is quite different since it maps a structured set
of types to allowed behaviors instead of a general set of types to a
structure. This is also why I think it is difficult to extrapolate the
usage of a such hierarchy if we haven't minimum experience with its use.

>>- True and False are (exclusive) specialization of TrueFalse by inheritance.
>>- Specialisation can be used to perform state complement (logical NOT)
>>because most specific specialisation are selected first.
>>
>>With these observations, it is easy to build logical tables with the 3
>>states by writing 4 specialisations (instead of 9).
>
>
> Hmm, it should be 8.
>
> = 2^3

no, 3^2

> 2 = the depth of the type hierarchy
> 3 = the number of parameters within the same hierarchy (2 arguments + the
> result)

the depth of the hierarchy has nothing to do here (except to reduce the
number of specialization required to fill the table by using some
properties you enumerate below). This is the number of argument to the
multimethod which matters, that is 2.

2 parameters, 3 states -> 3^2

> When Boolean and TriState are related types and both arguments and the
> result of AND are covariant then the dispatching table of AND will have 8
> slots:

I provided the truth table in my post.

> The algebraic properties of the dispatching table you observed for AND are
> determined by:
>
> 1. Dispatching parameters = the arguments and results in which the method
> is polymorphic = covariant of the involved parameters.
>
> 2. Symmetries along the parameters. Like commutativity (of +,*, AND etc),
> group inverses (of - to +, / to *), De Morgan rules etc etc. For example,
> relations as < possess symmetries like a<b <=> not b>=a. This also can
> reduce the number of signatures. However, note that symmetries often get
> violated upon inheritance. For example, should you extend R to a set of
> square matrices over R, you would loose commutativity of *.

Right and hopefully both specializations will not lead to the same
algorithm (e.g. commutativity is not lost but is not there). BTW
matrices are not set nor structure, but only a *representation* of
linear mapping. The non-commutativity of * is a property of linear mapping.

> 3. Properties of the domain sets of the involved types. Like existence of
> injective mappings between the values (generalization). This is as crucial
> as 2. When you extend R to C you loose order

because C is not an extension of R (or I misunderstand what you mean by
extension). R^* is an extension of R. Vector spaces are not extension of
C either, but C is a vector space. By the way, it is not simple to map
mathematical structures to type system. So this kind of example always
generate loooonnng discussions (which I would like to avoid, I am just
quering for experience, references or links.).

Regards,
ld.

"Dmitry A. Kazakov" <mailbox{}dmitry-kazakov.de> wrote in
news:12cnousl5msxh.1anmyqm356hwb$.dlg{}40tude.net:

>
> (in logic "uncertain" is usually denoted as _|_, flipped T)

In what logic ?

>
>> - True and False are (exclusive) specialization of TrueFalse by
>> inheritance. - Specialisation can be used to perform state complement
>> (logical NOT) because most specific specialisation are selected
>> first.
>>
>> With these observations, it is easy to build logical tables with the
>> 3 states by writing 4 specialisations (instead of 9).
>
> Hmm, it should be 8.
>
> = 2^3
>
> 2 = the depth of the type hierarchy
> 3 = the number of parameters within the same hierarchy (2 arguments +
> the result)
>
> When Boolean and TriState are related types and both arguments and the
> result of AND are covariant then the dispatching table of AND will
> have 8 slots:
>
> AND : Boolean x Boolean -> Boolean
> AND : Boolean x Boolean -> TriState
> AND : Boolean x TriState -> Boolean
> AND : Boolean x TriState -> TriState
> AND : TriState x Boolean -> Boolean
> AND : TriState x Boolean -> TriState
> AND : TriState x TriState -> Boolean
> AND : TriState x TriState -> TriState
>
> Taking into account commutativity of AND, the number of distinct
> signatures can be reduced to 6:
>
> AND : Boolean x Boolean -> Boolean
> AND : Boolean x Boolean -> TriState
> AND : Boolean x TriState -> Boolean
> == AND : TriState x Boolean -> Boolean
> AND : Boolean x TriState -> TriState
> == AND : TriState x Boolean -> TriState
> AND : TriState x TriState -> Boolean
> AND : TriState x TriState -> TriState
>
> Because TriState is a generalization of Boolean (or equivalently
> Boolean is a specialization of TriState)
>
> AND : Boolean x Boolean -> Boolean
> <= AND : Boolean x Boolean -> TriState
> AND : Boolean x TriState -> Boolean
> == AND : TriState x Boolean -> Boolean
> AND : Boolean x TriState -> TriState
> == AND : TriState x Boolean -> TriState
> AND : TriState x TriState -> TriState
> => AND : TriState x TriState -> Boolean

Without implication, your three-valued logic is not fully specified.

Laurent Deniau <laurent.deniau{}cern.ch> wrote in
news:em9a39$p4i$1{}cernne03.cern.ch:

> Number
> <- Integer
> <- Floating
> <- Complex
>

It is a silly hierarchy mathematically speaking because what is
'Number' ? Usual attempts to tie up mathematical structures in a naive
object hierarchy are doomed to failure. I guess it's due to lack of
mathematical education, a phenomenon regrettably common amongst computer
science types.


>
> I provided the truth table in my post.
>

You did not for implication, so your logic is underspecified.

> BTW
> matrices are not set nor structure, but only a *representation* of
> linear mapping. The non-commutativity of * is a property of linear
> mapping.

BTW, matrices are a structure allright, it's called a ring.

> By the way, it is not
> simple to map mathematical structures to type system.

Right.

On Tue, 19 Dec 2006 21:20:53 +0100 (CET), V.J. Kumar wrote:

> "Dmitry A. Kazakov" <mailbox{}dmitry-kazakov.de> wrote in
> news:12cnousl5msxh.1anmyqm356hwb$.dlg{}40tude.net:
>
>> (in logic "uncertain" is usually denoted as _|_, flipped T)
>
> In what logic ?

Ah, there are so many. Even for a tri-state logic one could take
"contradictory" T instead of "uncertain" _|_ as the third element.

> Without implication, your three-valued logic is not fully specified.

Right. That depends on the definition of implication. (not x) V y is well
defined in tri-state logic because not _|_ = _|_. But it would be a bad
implication to take. A better one is ~xVy, where ~_|_=T. That is not closed
in tri-state logic. It is in four-state Belnap logic:

x y x=>y
------------------
0 0 1
0 1 1
0 _|_ 1
1 0 0
1 1 1
1 _|_ _|_
_|_ 0 T
_|_ 1 1
_|__|_ 1

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de