2015-07-02 20:09 GMT+02:00 Steve M. Robbins
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".
Exactly. A (non-mongel) monad has two states. A Boolean type also has two states, but so does anything else that has two states, e.g. enum {Up, Down}; or enum {Male, Female}; The reason people choose to use Boolean values is because at some point they need Boolean arithmetic. Unless I am missing something, you need not exercise the Boolean algebra on the state of the result of the asynchronous operation. It seams that the conceptual mapping of the state of the monad onto a Boolean type brings no value to the programmers that will be launching asynchronous tasks. A mongel monad has three states. But there are many things out there that have three states, and it does not mean they have to be mapped on a tribool type. For instance, a file can be empty or can contain some data or be non-existent. But why would I ever think of mapping it onto a tribool?
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.
Maybe that will explain it. Regards, &rzej