Subject: Re: [boost] Monad (was: Re: [Boost-users] [afio] Formal review of Boost.AFIO)
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-08-26 22:43:20
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 (I'm
> 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 their
> own monad types.
That's exactly what it does. It's a framework for creating bespoke
future and monad types. 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.
The idea is that no one ever need implement the Concurrency TS
themselves ever again. Just pick up a copy of Boost.Monad/Outcome.
Write your policy class for your custom variant. Profit.
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk