|
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.
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 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/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk