Re: [boost] [Fit] Review

Subject: Re: [boost] [Fit] Review
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2016-03-10 01:33:59

Le 10/03/2016 01:12, Paul Fultz II a écrit :
>
> On Wednesday, March 9, 2016 at 8:50:01 AM UTC-6, Zach Laine wrote:
>>
>> There are a number of adaptors that I find have obscure names:
>>
>> by() is a projection; why not call it project()?
>>
> I chose `by` because of how it is used linguistically. That is you write:
> `sort(v.begin(), v.end(), by(&Employee::Name, _<_))` which I read "sort by
> employee name". Also, if I write `by(decay, construct<std::tuple>())`, I
> read
> "construct tuple by decay". In haskell, it uses `on` for this adaptor, which
> is what I originally called it. `project` is a more straighforward name.
`by` is a comparator while `projet` is a projection.
>   
>
>> compress() is defined in terms of "fold", with a link to the Wikipedia
>> page
>> for same; why not call it foldl()?  Similarly, reverse_compress() should
>> be
>> foldr().
>>
> Not `foldr`. This is because `foldr` is symetrical. For example, `foldl` and
> `foldr` should produce the same results:
>
>      foldl(_+_, std::string())("Hello", "-", "world"); // "Hello-world"
>      foldr(_+_, std::string())("Hello", "-", "world"); // "Hello-world"
It would be good to use a binary function that has two different types 
to see the difference in behavior.
> However, compress and reverse_compress work like this:
>
>      compress(_+_, std::string())("Hello", "-", "world"); // "Hello-world"
>      reverse_compress(_+_, std::string())("Hello", "-", "world"); //
> "world-Hello"
>
> I was reluctant to call it `fold` as it seems to imply some data structure
> to
> fold over, whereas this is simply an adaptor. I used the word compress as
> its
> a another name used for fold. However, it seems more people would prefer to
> use `fold` and `reverse_fold`.
You are folding the parameter pack. I like those. and I would like also 
fold_left, fold_right.
>   
>
>> flow() is a super obscure name!  Why is this not reverse_compose() or
>> similar?
>>
> I actually got the name from underscore.js. The reason why I chose this name
> instead of `reverse_compose` is because when this is used with pipable
> functions it seems confusing:
>
>      reverse_compose(
>          filter([](int i) { return i < 3; }),
>          transfrom([](int i) { return i*i; })
>      )(numbers);
>
> With the word 'reverse' there, it almost looks as if it computes the
> pipeline
> in reverse order, which it doesn't. So I would prefer a name without reverse
> in it.
Would pipe works better?
>   
>
>> indirect() could more easily be understood if it were called deref() or
>> dereference().
>>
> Well, `indirect` is how it is commonly called in libraries such as
> Boost.Range, range-v3, and PStade libraries. So I would like to keep the
> name
> consistent with other similar constructs.
>   
Could you tell us what indirect is in range-v3, what is the signature 
and the semantics. I don't see it is used for the same purposes, but 
maybe I'm wrong.

ref(flv) is a callable that wraps an lv
indirect(ptr) is a callable that wraps a ptr and deref it before calling

deref/dereference will only relate the dereference action, but not the call.

deref_on_call is too long?
>> I don't feel as strongly about partial(), but I think it might be clearer
>> if
>> it were called partial_apply() or curry().
>>
> Hmm, I don't think a name with `apply` in it is good name for an adaptor.
Maybe you could explain why curry is not a good name here? What is the 
difference between partial an currying a function.
>   
>
>> conditional() should be called invoke_first(), call_first_of(), or
>> similar.
>>   I
>> find it too easy to confuse with if_().
>>
I agree conditional is not a good name.

> I see, I was trying to describe an adaptor where you could put functions
> with
> conditions in it. Other people, seem to prefer a name like `linear`, so I
> might use that instead.
This function is related to match. The difference is that one select the 
best matching overload and those must be exclusive and the other the 
first matching overload and the match can be inclusive. I would like to 
see the semantics on the name, but I have not a concrete proposal.

We need to take in account that this is an adaptor, so there is no call, 
so `invoke_first` or call_first_off will not work. Those functions 
creates another function object that applies a different algorithm to 
select the overloaded functions when called.

I've used
     overload -> match
     first_overload -> conditional

I prefer those, but I'm not yet happy with. Naming is difficult.
>>
>>   
>>
>>
>>    * Documentation
>>
>> The Quick Start section is good at showing a compelling motivating case
>> for
>> using the library.  The result at the end of the section looks like a very
>> good start on a "Scrap Your Boilerplate" solution for simple, dump-style
>> printing.  It's relatively easy to read and write.
>>
>> The documentation is what needs the most work, from what I've seen.  The
>> Quick
>> Start is quite nice, but then there are some things that are
>> underexplained
>> in
>> the subsequent Overview and Basic Concepts sections.  For instance, why
>> are
>> these macros used everywhere and what do they do?  They should be used for
>> the
>> first time after showing what the expanded code looks like.
>
> I don't think the docs should show the expansion of the macros, that is part
> of the implementation and not interface. I could show an "idea" what is is
> expanding to, with explanation of what else it is doing beyond the simple
> explanation.
I agree hat it is absolutely needed to show the exact expansion, but it 
is clear that the user wants to know what is behind the scenes.
>   
>
>> This will
>> justify
>> their use for those users that want them, and show those that don't what
>> they
>> can write instead.
>>
>
> I could show an alternative without the macros, but I would prefer to put
> that
> in the Advance section. In the introduction of the library, I would rather
> show the constructs that can be easily used without a need to explain a
> bunch
> of caveats.
I will put all of them in the advanced section. I would no mention them 
in the introduction as the user can create the HOF locally or use a factory.

Best,
Vicente