Subject: Re: [boost] GSoC 2014 - Functional - Monad
From: Ding Xiangfei (a0113627_at_[hidden])
Date: 2014-03-11 14:26:28
Vicente J. Botet Escriba <vicente.botet <at> wanadoo.fr> writes:
> Le 05/03/14 16:36, Ding Xiangfei a Ã©crit :
> > Hello, Boost. This is Xiangfei, a first year CS student from National
> > University of Sinagpore. I am familiar with C++ template programming and
> > learnt a little functional programming language by myself. Therefore I
> > the monad project in boost will be very interesting and useful.
> Hi Ding and welcome to Boost
> Which functional language do you know?
> > This is my first time applying for GSoC. I have past boost use
> > it is my first time also to contribute in Boost library.
> > I have a question for the implementation of monad. What is the degree of
> > integration of this module with other Boost utilities other than
> > containers? Thank you.
> There is no implied dependencies on any Boost library. Of course, there
> is no need to reinvent the wheel.
> However at least the library must provide mapping for boost/std::future,
> boost::optional and the on going boost::expected classes between others.
> Mapping to containers could be provided in order to check for the
> ability to configure it, but it is not mine main goal for the library.
> Been able to understand the implementation of the Pure library is a
> must. (https://github.com/splinterofchaos/Pure)
> Please take a look at it a let me know how do you fill with this kind of
> I would appreciate if you can give you impression of the library, what
> you like, what you would change, any additional feedback ....
> Unsubscribe & other changes:
a functional programming language which includes list manipulation, function
composition, lazy computation (memoization), etc. I am currently learning
Scala and Haskell. I also have understood the concept of Monad as well after
reading the Haskell Wiki.
boost/std::future.then fits in the Monad concept quite well. The future
class is used as the container of computed results from the previous task,
and the method then() is to apply a function to these results, which can
detach from the main thread if launch::async is used. The template for
categories and monad can be overloaded to accept future objects and allow
mappend a functor to a future object to give an asynchronous function call.
This chaining of functions is similar to how Monads. The support for
std::future in Monads will be useful because with this feature, algorithms
like quick sort or merge sort can work in a multithreading fashion by
packing the sub-routines into Monads and branches out.
boost::expected, which was the project in previous year's GSOC,
boost::expected and boost::optional are also monads. It can be seen as a
pair of two values, which are a value and a validity indicator. It is
implemented by classes "Maybe", "Either" in the library and this can be our
blueprint in the implementation of expected and optional.
I have spent time carefully reading the code of the Pure library and think
that the Pure library provides a good framework for implementation of
monads. Here, I propose an extension to monad templates in the library to
make monads for std::future using the then() method. I also propose monads
containing functions as well that enables chaining of functions and
potentially currying. The implementation may slightly differ from the Pure
library because some parts of functors for specific categories can be moved
inside monads to reduce compilation time on template resolution. My concern
is that when chaining of functions is frequent, compilation time may
increase significantly since this library relies on template heavily and
functors are placed outside monad definitions.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk