Subject: Re: [boost] GSoC 2014 - Functional - Monad
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2014-03-27 03:49:11
Le 27/03/14 02:45, Ding Xiangfei a écrit :
> Ding Xiangfei <a0113627 <at> nus.edu.sg> writes:
>
>> Vicente J. Botet Escriba <vicente.botet <at> wanadoo.fr> 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:
>>>> https://docs.google.com/document/d/1sdgO63-
>> 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
> to
>> 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://listarchives.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
> 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://listarchives.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
>
>
Hi Ding,
it is too late to improve the proposals.
We could continue the discussion once the slots of Boost are know and
the projects assigned.
Best,
Vicente