Re: [boost] Ternary logic programming (was: Re: [variant] Maintainer)

Subject: Re: [boost] Ternary logic programming (was: Re: [variant] Maintainer)
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-07-02 06:10:43

On 1 Jul 2015 at 21:07, charleyb123 . wrote:

> So, after having looked hard for alternatives, I actually like your syntax
> (because I have a hard time finding a more obvious way to do that with
> if/else).

I ended up a similar place of not being able to think of anything 
better than meets the criteria.

> But, I also agree with other comments in this thread that it annoys most
> programmers to demand explicit-comparison-testing-with-bool.  We expect
> implicit-bool-conversion, and frankly, it is quite awkward to do a
> three-way-division using a boolean if/else construct.

Ah, I suppose I didn't mention my solution to that yet.

My tribool won't convert implicitly to bool, but anything converting 
to a tribool also converts to a bool. So, for monad<T>:

    //! \brief Same as `true_(tribool(*this))`
    constexpr explicit operator bool() const noexcept;
    //! \brief True if monad contains a value_type, false if monad is 
empty, else unknown.
    constexpr operator tribool::tribool() const noexcept;

So, if we have:

monad<int> a;

We can do via the explicit bool conversion:

if(a) { execute if a has value }
if(!a) { execute if a does not have value i.e. is empty or 
errored/excepted }

This is natural to program against. But if we want the ternary logic 
we can also do:

if(true_(a)) { execute if a has value }
if(false_(a)) { execute if a is empty }
if(unknown(a)) { execute if a is errored/excepted }

This is another appeal of the free function based ternary logic 
design. You push the implicit bool conversion onto the thing with 
tribool state. The library user gets both boolean and ternary idioms 
according to their wont.

Does this appeal to the list more? I realise I didn't explain myself 
well. As usual.

> I *really* like that you are pursuing it, though.  Like pornography, we
> should mostly be able to recognize elegance and expressiveness when
> somebody demonstrates an elegant way to do it.

I have noticed that extremely few find my code nor design elegant nor 
expressive :)

We'll see during the AFIO review in two weeks. My main goal between 
now and then is to use these monadic futures to make the AFIO API 
much more conventional than at present, so I'm hoping to hammer down 
a whole load of unexpected rough edges for the conventional Boost 
community member. I'm hoping that will be enough to get it passed 
review and into Boost.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/