Boost logo

Boost :

Subject: Re: [boost] Ternary logic programming (was: Re: [variant] Maintainer)
From: charleyb123 . (charleyb123_at_[hidden])
Date: 2015-07-01 23:07:42


On Wed, Jul 1, 2015 at 6:49 PM, Niall Douglas

> On 1 Jul 2015 at 15:53, charleyb123 . wrote:
>
> > Under an alternative model, the common construct would be something like:
> >
> > void foo(...) {
> > return switch_(...) {
> > ...
> > }
> > }
> >
> > ... and you manage your true/false/unknown cases explicitly. Works great
> > for asynchronous and distributed, and for interfacing-with-hardware.
>
> That's exactly what Rust does. In fact, you'll find yourself either
> writing match x { patterns ... } or using monadic programming. A lot,
> because there is little other choice.
>
> Out of interest, what do you think of my free function ternary logic
> programming:
>
> 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.
>

I'm uncertain it's possible to reform if/else (a boolean construct) to do
ternary or MVL things. Or more likely, I'm uncertain it's possible to
reform programmers that are trained in if/else as a binary construct.

It's a tricky problem. I think your syntax is the best we can do with
if/else, and the boost::indeterminate() similarly "inverts" the separation
of "unknown" from the "true/false" values.

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).

You made a comment in a previous email that your "tribool" approach was
"paranoid" in addressing "unknown" -- YES, TOTALLY AGREE! That's the only
way to do this, or you are totally screwed with the original problem (of a
false assumption expressed through mistaken logic that was not caught by
the compiler).

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.

IMHO, this is the key problem: if/else is just not very composable. Like
the classic book, "The Art of Software Testing" discusses, refactoring
if/else is amazingly tough (and branch analysis is a combinatorial
explosion). It's hard to express and reason about, and refactoring usually
means a rewrite.

We can set up an "if/else-ladder" to otherwise do what a switch would do,
but in the end, switch ends up being more clear-and-expressive. Easier to
support and extend.

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.

--charley


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