Le 27/11/14 12:51, Joaquin M Lopez Munoz a écrit :
Vicente J. Botet Escriba <vicente.botet <at> wanadoo.fr> writes:
Le 17/11/14 18:14, Joaquin M Lopez Munoz a écrit :
Just to throw some idea in, there's an altenative based on the following approach:[...] we could *lift* f so that we write this instead:
auto ret=lift<f>(arg1,...,argn);
with the same semantics. This is a case of *monadic lifting* as explained (and implemented) at
http://bannalia.blogspot.com/2014/03/monadic-lifting-in-c.html Hi Joaquin, I missed your post.
I like this, of course :)
If I understood your blog, this should be something like
auto ret = lift<optional, f>(a1, ..., an);
Or could the optional template be deduced? It would be more like
lift<optional>(f)(a1,...,an)
but in any case the particular monad being lifted to (here optional) must be specified. In TBoost.Expected we have
auto x = fmap(f, a1, ..., an); that do the same and the type of the result is deduced from f and ai. The lift you propose can not deduce the result type directly as it doesn't knows yet ai, but couldn't this be done at the call of the lifter? template <class F struct lifter { F f; lifter(f) : f(f) {} template <class ...Args> auto operator()(Args&& ...args) -> common_type_t<apply<type_constructor<Args>, decltype(f(args.value()...))>...> { ... } }; lifter<F> lift(F f) { return lifter<F>(f) }; The result type could be the common type of applying the associated type constructor to the result of the function call. If fmap was a curryable function we could be able to do auto x = fmap(f)(a1, ... an); This doesn't mean that the ability to force the 'Functor' (optional) is a bad thing.
This lift operation is a good thing when you have a function. The problem is that people don't have always a function to call, they have just code to execute. The closer we have are lambdas
auto res = fmap(o1, ..., on , [](a1, ..., an) { // the code }); You can lift lambdas as well:
auto res=lift<optional>([](int x,int y){ return ...; })(o1,o2);
Of course. Thanks for recalling it to me. I wanted to share this (from http://en.wikipedia.org/wiki/Nullable_type) Nullable references were invented by C.A.R. Hoare <http://en.wikipedia.org/wiki/C.A.R._Hoare> in 1965 as part of the Algol W <http://en.wikipedia.org/wiki/Algol_W> language. Hoare later described their invention as a "billion dollar mistake".^[4] <http://en.wikipedia.org/wiki/Nullable_type#cite_note-4> This is because object pointers that can be NULL require the user to check the pointer before using it and require specific code to handle the case when the object pointer is NULL. [4] Tony Hoare (2009). "Null References: The Billion Dollar Mistake" <http://qconlondon.com/london-2009/presentation/Null+References:+The+Billion+Dollar+Mistake>. # QCon London.<http://developer.apple.com/library/ios/documentation/cocoa/conceptual/ProgrammingWithObjectiveC/WorkingwithObjects/WorkingwithObjects.html#//apple_ref/doc/uid/TP40011210-CH4-SW22> Sorry the link doesn't works. I would appreciate a lot a valid link. An abstract could be found here https://www.linkedin.com/pulse/article/20141126171912-7082046-tony-hoare-inv... Best, Vicente