Ding Xiangfei
Vicente J. Botet Escriba
writes: Le 17/03/14 08:46, Ding Xiangfei a écrit :
Hello, Vincete,
Thank you for the previous advice. Based on the ideas I had, I have
written a draft proposal for this
project. The Google Doc link is as follow:
SFo9IhPvfcwNSrwVEey9Pl9V9ftmZDPzrqO4/edit?usp=sharing
As the proposal is not final and I am still thinking about any new
ideas about monads, I would like to invite you for comments and evaluation on
the manageability and viability of this project.
Besides, I also added some experimental features that I would like
make during (hopfully) or after this
summer. Comments on these features are
also appreciated.
Hi,
there is something I find incoherent on the prose. Fisrt you say "the conception of monads allows functional programming languages to perform a sequence of instructions just as imperative languages. Last you say that "monads will simplify function chaining and exception handling when the code is written in a functional fashion".
C++ is a multi-paradigm language that supports already the imperative style and a clean exception handling machinery. How monads can help C++? Why it would be worth to write programms in C++ in a functional monadic style? To be able to perform a sequence of instructions? C++ has already all that. Why monads style will be useful in C++?
How do you plan to "simplify type resolution and compile time"?
Could you tell more about "dynamic typing of monads"?
Could you elaborate on the operations the monads you plan to provide will support? In addition to monad operations do you plan to provide other? e.g. what list operations? Waat do you mean by asynchronous function chaining? Error-handling?
Could you show an example of user code making use of monads interface?
Could you show an example of developer code making a type behave as a monad?
Do you plan to use CRTP? Do you plan to use dynamic polymorphism?
What kind of performance would you evaluate? And to which alternative would you compare? Do you have already an idea of the bechmarks 1 and 2?
Having a concept without associated algorithms is not too useful. Do you have examples of algorithms that build on top of the monads interface?
Do you think that you will be able to finish with a Boost ready for review library at the end of the program?
Globally your proposal could be improved a lot by adding more detail.
HTH, Vicente
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hello Vicente,
Thank you very much for your valuable advice. As I am amending the proposal I will give some examples of the interface and algorithms running on it. In order to make the project more manageable, I decided not to go too ambitious and trimmed out the part on 'dynamic typing' (because I think
to that
it is trivial at this moment) and trying to increase type-resolution efficiency to make sure things just work nicely before the end of summer.
Regards, Ding Xiangfei
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hello Vicente, I have replied the comment on the proposal. Just in case, I will explain wwhat I have done recently here. I have make the part of the implementation working for the bitonic sorter example. Here is the link to the source code: https://gist.github.com/dingxiangfei2009/4970b62159cd1dca1868. I was not aware of the wait_for_all issue, so that one was re- implemented for illustrative purpose. Besides, then() method was not implemented, so a rudimentary implementation was used to replace that method. I also read the documentation on boost::optional and wrote a skeleton for optional monad. I was not clear whether there was a proposal for expected class, but I indeed found an implementation written by ptal on github. I took it as a reference. I hope that you can give some feedback on this sample code, what are the improvements to be made and what I have overlooked, etc. Thank you very much. Have a nice day. Regards, Ding Xiangfei