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. Tony Sent from my portable Analytical Engine ------------------------------ *From:* "Niall Douglas" <s_sourceforge@nedprod.com> *To:* "boost@lists.boost.org" <boost@lists.boost.org> *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 or: 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. Niall -- ned Productions Limited Consultinghttp://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/