
Boost : 
Subject: Re: [boost] Ternary logic programming
From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 20150705 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.
Tony
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 ifstatements. In that case, I tend to agree with Lee's enum
> and switch suggestion, which also extends well into multivariate 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 ifstatements, 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/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk