|
Boost : |
Subject: Re: [boost] Ternary logic programming (was: Re: [variant] Maintainer)
From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2015-07-02 13:38:42
On Thu, Jul 2, 2015 at 1:28 PM, Niall Douglas <s_sourceforge_at_[hidden]> wrote:
> On 2 Jul 2015 at 8:31, Steve M. Robbins wrote:
>
>> > > In your monad application, I have never seen operators || or && mentioned,
>> > > so there seems to be no reason to adapt names "true" and "false" for the
>> > > three states. You might as well call them "A", "B" or "C", or to more
>> > > closely reflect your application: "value", "failure", "internal_error".
>> > >
>> > > Am I missing something?
>> >
>> > Hopefully I explained it in my reply to Charley.
>>
>> I didn't see this question addressed.
>
> A monad has an expected and an unexpected outcome. That naturally
> maps to true and false.
>
> My mongel monads can also be empty. That implies a ternary state. No
> one can disagree that the expected state ought to map to true. A
> valid disagreement is whether empty or unexpected should be false or
> indeterminate.
>
> I chose the errored/excepted state to be the indeterminate, because I
> felt that null and value_type states are exactly what they are, but
> an error_code and especially an exception_ptr is quite literally
> unknown until you interrogate/rethrow it.
>
Just my 2 cents, but from that description, I'd map empty to unknown
and failure to false.
Empty means I haven't done it yet, I'll let you know when I know.
Currently it is unknown.
Success means yes I've done it. TRUE!
Failure means no I couldn't. FALSE.
But that's for something like expected<T,E>. For optional<T>, empty
currently maps to false, at least in boost::optional and
std::experimental::optional. In a functional language with "Maybe T",
empty really does map better to unknown - I do not yet know the value
of T. We force it into boolean because that's what we are comfortable
with.
Hmmm, optional<bool> would have less problems if empty mapped to
unknown instead of false.
Tony
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk