On 27 Aug 2015 3:46 am, "Niall Douglas"
On 26 Aug 2015 at 5:57, Glen Fernandes wrote:
Paul wrote:
these are all *outcomes* - of varying types of varying and unspecified Thingy.
Niall wrote:
I like Boost.Outcome and boost::outcome::basic_outcome<Policy>. Do these make sense however: outcome<T>: Can be empty/T/error_code/exception_ptr. result<T>: Can be empty/T/error_code. option<T>: Can be empty/T.
Isn't "Outcome" no less generic and unspecific as "Result"? All of Boost.Monad, Boost.Outcome, or Boost.Result, seem like terrible names
to me.
Choice between the pan and the fire.
We already name specific result types for the kind of result they are
glad boost::optional is not boost::result). Why not name monad types for the specific kind of monad they are?
Unless this "Monad" library isn't about offering a concrete type called "boost::monad" but instead is just a library to enable someone write
(I'm their
own monad types.
That's exactly what it does. It's a framework for creating bespoke future and monad types.
A Boost.Monad library that would provide a monad_adaptor a la Boost.Iterator could indeed be useful, but that doesn't seem to be the case here.
You define your policy implementations classes and feed them to basic_monad<Policy> or basic_future<Policy> as needed. The library itself provides three monad specialisations and six future specialisations by stamping out the nine policies for each of those.
Unfortunately the documentation for the policy is literally an empty line. I have looked at the detail/monad_policy.hpp file, but beyond customising the storage, I can't see any hook to customise the behaviour. Could you show us a custom policy implementation for a list monad? -- gpd