Discussion:
[boost] [outcome] where is the monadic style tutorial?
Mathias Gaunard via Boost
2017-06-01 09:12:52 UTC
Permalink
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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Andrzej Krzemienski via Boost
2017-06-01 09:44:17 UTC
Permalink
Post by 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_example.md

Regards,
&rzej;

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Mathias Gaunard via Boost
2017-06-01 11:53:28 UTC
Permalink
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 <
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.
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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Andrzej Krzemienski via Boost
2017-06-02 08:31:36 UTC
Permalink
Post by 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;

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Niall Douglas via Boost
2017-06-01 18:39:38 UTC
Permalink
Post by Mathias Gaunard via Boost
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/


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Loading...