Boost logo

Boost :

Subject: Re: [boost] Ternary logic programming
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2015-07-03 01:46:53


Le 02/07/15 19:28, Niall Douglas a écrit :
> 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.

A monad is something different and more general than what you describe.
Anyway the logic you describe will be closer to a specific kind of
monads, the monad error.
>
> My mongel monads can also be empty. That implies a ternary state. No
> one can disagree that the expected state ought to map to true. A
> valid disagreement is whether empty or unexpected should be false or
> indeterminate.
In Haskel there is what they name Monad Transformers. Monad Transformers
are in some way concrete classes that are a model of Monad that 'wraps'
another Monad. You have two levels of Monads. This give a 3-logic state.
You can take a look at this introduction to Monad transformer [1].

How to implement monad transformers efficiently in C++ is another
question, but having in mind that your 3-logic state can be seen as a
Monad Transformer could help to make the good abstractions.
> I chose the errored/excepted state to be the indeterminate, because I
> felt that null and value_type states are exactly what they are, but
> an error_code and especially an exception_ptr is quite literally
> unknown until you interrogate/rethrow it.

HTH,
Vicente

[1]
https://github.com/kqr/gists/blob/master/articles/gentle-introduction-monad-transformers.md#transformer


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