Vicente J. Botet Escriba
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
have
learnt a little functional programming language by myself. Therefore I find 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 experience, but 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 sequences and 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 code. I would appreciate if you can give you impression of the library, what you like, what you would change, any additional feedback ....
HTH, Vicente
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hello, Vincete, Sorry for this delayed reply. Yes, I have learnt a subset of Javascript as 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. Regards, Ding Xiangfei