Boost logo

Boost :

Subject: Re: [boost] Ternary logic programming (was: Re: [variant] Maintainer)
From: Steve M. Robbins (steve_at_[hidden])
Date: 2015-07-02 14:09:56


On July 2, 2015 06:28:58 PM Niall Douglas 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. [...]

Sorry: the question is not "why does it have three states?" That is clear.
The question is "why do you call two of those states 'true' and 'false'?" I
don't personally find the mapping "natural".

> > Why even bring up "tribool" at all in this context? It seems like an
> > invitation for people to make buggy / unclear code.
>
> Maybe. It's why I've been asking here. As I mentioned, I can see a
> use case for this. If you watch Charley's talk from C++ Now, I found
> it compelling for its niche use case.

I confess that I haven't been paying close attention to this thread, so I've
missed it. What is the use case that you can't use the more-explicit
has_value()/has_error()/etc?

 
> I'll know the practical experience in a few weeks from now as I
> integrate these into AFIO and get some practice with constructing
> ternary AND/OR sequences from them. If I find them problematic, I'll
> remove tribool support completely.

Not that I dare suggest what you do with your time, but: why not write it first
with the more clear has_value()/has_error()/etc and introduce the tribool only
if you find that problematic?

-Steve




Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk