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:16:31

On 2 Jul 2015 at 10:40, Andrzej Krzemienski wrote:

> > tribool t;
> > if(true_(t)) { /* true */ }
> > else if(false_(t)) { /* false */ }
> > else if(unknown(t)) { /* other state */ }
> >
> > Nobody here seemed to like it. I am looking for something the average
> > programmer will notice immediately and not accidentally assume it's
> > boolen logic going on here.
>
> Because I cannot see the direct connection between the three-state monad
> you are exploring and a ternary logic (like in Boost.Tribool), I might be
> missing something obvious, but why do you insist on calling the states
> "true" and "false"? I know why Boost.Tribool does it: because it provides
> operators || and && that intuitively implement "true", "false" and "I do
> not know" concepts.
> 
> 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.

There are also accessor member functions on monad, so 
empty()/has_value()/has_error()/has_exception(). And the continuation 
and bind operators can also select on state. You can also simply do 
monad<T>.get() wrapped with a try...catch block, just as with future.

I've given four "styles" of doing logic from a monadic state. Each 
has its pros and cons for a given situation, generally the higher 
order functions like bind are lovely to use but impact build times, 
which is why those are disabled by default and only enabled via a 
compile time macro.

Niall

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