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