[outcome] where is the monadic style tutorial?
Hi, I just took a quick look at outcome today and I don't really understand what it is doing. I expected to have some kind of mechanism to manage control flow with propagation between states only happening if the previous expression in the chain resulted in an expected value, like with the Expected monad. I searched throughout the documentation and didn't find any. Why is there no example of this? More than how the error state is captured and stored or how to capture custom errors, I believe the programming model is what the tutorial should really focus on.
2017-06-01 11:12 GMT+02:00 Mathias Gaunard via Boost
Hi,
I just took a quick look at outcome today and I don't really understand what it is doing.
I expected to have some kind of mechanism to manage control flow with propagation between states only happening if the previous expression in the chain resulted in an expected value, like with the Expected monad. I searched throughout the documentation and didn't find any.
Why is there no example of this? More than how the error state is captured and stored or how to capture custom errors, I believe the programming model is what the tutorial should really focus on.
It has been agreed upon that the tutorial needs to undergo a rewrite. Meanwhile, maybe the following examples can help: https://github.com/akrzemi1/__sandbox__/blob/master/outcome_intro2.md https://github.com/akrzemi1/__sandbox__/blob/master/outcome_practical_exampl... Regards, &rzej;
Ok so the approach is to do auto expected1 = do_statement1(); if (!expected1) return expected1; auto expected1_value = expected1.value(); auto expected2 = do_statement2(expected1_value); if (!expected2) return expected2; auto expected2_value = expected2.value(); return do_statement3(expected2_value); with that logic being encoded by the TRY macros? I'd rather use continuation passing style, was that considered? return expected_flow(do_statement1)
[](auto const& expected1_value) { return do_statement2(expected1_value); } [](auto const& expected2_value) { return do_statement3(expected2_value); } ;
On 1 June 2017 at 10:44, Andrzej Krzemienski via Boost < boost@lists.boost.org> wrote:
2017-06-01 11:12 GMT+02:00 Mathias Gaunard via Boost < boost@lists.boost.org> :
Hi,
I just took a quick look at outcome today and I don't really understand what it is doing.
I expected to have some kind of mechanism to manage control flow with propagation between states only happening if the previous expression in the chain resulted in an expected value, like with the Expected monad. I searched throughout the documentation and didn't find any.
Why is there no example of this? More than how the error state is captured and stored or how to capture custom errors, I believe the programming model is what the tutorial should really focus on.
It has been agreed upon that the tutorial needs to undergo a rewrite. Meanwhile, maybe the following examples can help:
https://github.com/akrzemi1/__sandbox__/blob/master/outcome_intro2.md https://github.com/akrzemi1/__sandbox__/blob/master/outcome_ practical_example.md
Regards, &rzej;
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost
2017-06-01 13:53 GMT+02:00 Mathias Gaunard via Boost
Ok so the approach is to do
auto expected1 = do_statement1(); if (!expected1) return expected1; auto expected1_value = expected1.value();
auto expected2 = do_statement2(expected1_value); if (!expected2) return expected2; auto expected2_value = expected2.value();
return do_statement3(expected2_value);
with that logic being encoded by the TRY macros?
I'd rather use continuation passing style, was that considered?
return expected_flow(do_statement1)
[](auto const& expected1_value) { return do_statement2(expected1_value); } [](auto const& expected2_value) { return do_statement3(expected2_value); } ;
Does this solution scale to more complicated control flows? How would the following flow be represented by this style? ``` auto rslt1 = fun1(); RETURN_IF_FAILED(rslt1); auto rslt2 = fun2(); RETURN_IF_FAILED(rslt2); auto rslt3 = fun3(rslt2); RETURN_IF_FAILED(rslt3); return fun4(rslt1, rslt3) ``` Regards, &rzej;
I expected to have some kind of mechanism to manage control flow with propagation between states only happening if the previous expression in the chain resulted in an expected value, like with the Expected monad.
The Expected proposal no longer implements monadic control flow, it has been hived off into a separate paper due to being contentious. Outcome's monadic control flow API was disabled and hidden for this review as we had enough to review without that. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
participants (3)
-
Andrzej Krzemienski -
Mathias Gaunard -
Niall Douglas