Re: [boost] [optional] Safe optional

Subject: Re: [boost] [optional] Safe optional
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2014-11-27 20:01:24

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-invention-of-the-null-reference-a-billion-dollar-mistake

Best,
Vicente