Boost logo

Boost :

Subject: Re: [boost] Ternary logic programming
From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2015-07-05 01:54:07

Sorry for top posting, I blame my tablet.

I see Empty as "I do not know *yet*" (like future). ie Empty == "Value or
Error eventually"
So I imagine "Empty && Error" as "(Value or Error) && Error". And for &&
it doesn't matter what the Empty is, the end result of anything || false ==
false ie Error.

So Error && anything is Error. (false && anything is false)
And Value || anything is Value. (true || anything is true)

That leaves Error || Empty and Value && Empty.
Error || Empty == Empty because (thinking of Empty as "unknown right now,
might change in future"), you need to leave the chance that Empty becomes
Value and the result of Error || Value is Value.
Or looking at it as Empty == (Value or Error) ie 'or' not '||' because
Empty is unknown:
       Error || Empty
== Error || (Value or Error)
== (Error || Value) or (Error || Error)
== (Value) or (Error)
== (Value or Error)
== Empty

Similarly, Value && Empty == Empty

Not sure if it makes complete sense to look at Empty as "Value or Error
eventually", but I think you get a reasonable truth table out of it, and it
might apply well to your futures.


Sent from my portable Analytical Engine

*From:* "Niall Douglas" <s_sourceforge_at_[hidden]>
*To:* "boost_at_[hidden]" <boost_at_[hidden]>
*Sent:* 4 July, 2015 11:26 AM
*Subject:* Re: [boost] Ternary logic programming

On 3 Jul 2015 at 11:45, Bjorn Reese wrote:

> > Out of interest, what do you think of my free function ternary logic
> > programming:
> So far, the discussion has focussed on how the ternary operators should
> behave in if-statements. In that case, I tend to agree with Lee's enum
> and switch suggestion, which also extends well into multi-variate logic.

My tribool allows switch and enum if you want it. It's just it
requires a bit more typing, and I dislike typing :)

> If we want to use the ternary logic in if-statements, then we should
> address composite conditions. For instance, what should the following
> evaluate to?
> if (Empty && Value) {}
> if (Empty && Error) {}
> if (Empty && Empty) {}
> The question really boils done to what influence Empty has. Do we want
> it to influence the results, or should it act like a "don't care" value?

That's exactly the nub of the problem. Which ought to be dominant
over the other, empty or errored? i.e. is it:

Empty < Errored < Valued

i.e. Empty && Errored = Empty


Errored < Empty < Valued

i.e. Empty && Errored = Errored.

Me personally, I chose the Kleene logic because I felt Empty is like
NaN in floating point, so it is always dominant.

And I suppose we can retain that, even with Errored => False, Empty
=> Unknown, with the appropriate truth tables.

The tricky part is which is the best design? I'm not sure if that's
answerable from a purely top down approach.


ned Productions Limited Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at