Re: [boost] [Fusion] Some ideas

Subject: Re: [boost] [Fusion] Some ideas
From: TONGARI (tongari95_at_[hidden])
Date: 2013-02-03 06:27:01

2013/2/3 Joel de Guzman <djowel_at_[hidden]>

> On 2/3/13 4:07 PM, TONGARI wrote:
>
>> 2013/2/3 Joel de Guzman <djowel_at_[hidden]>
>>
>>  On 2/3/13 11:50 AM, TONGARI wrote:
>>>
>>>  2013/2/3 Joel de Guzman <djowel_at_[hidden]>
>>>>
>>>>   On 2/2/13 3:52 PM, TONGARI wrote:
>>>>
>>>>>
>>>>>   Hi,
>>>>>
>>>>>>
>>>>>> Here are some ideas come up when writing some associative mapping
>>>>>> algorithm/views.
>>>>>> I think it'd be nice to have:
>>>>>> * Auxiliary function 'eval' to force the evaluation of transform-like
>>>>>> view
>>>>>>      e.g. fusion::eval(fusion::******transform(a, b,
>>>>>> some_void_return_ftor))
>>>>>>
>>>>>>
>>>>>>  How's that any different from as_vector, as_list, etc. ?
>>>>>
>>>>>
>>>>
>>>> They cannot take voids.
>>>>
>>>>
>>>>   Also, what will be the container type of the result of "eval" ?
>>>>
>>>>>
>>>>>
>>>>
>>>> Void. Just to trigger each transformation.
>>>>
>>>>
>>> Do you have a use-case?
>>>
>>
>>
>> e.g.
>>
>>      eval(mapping(view(dst), src, _1 = _2))
>>
>
> Sorry, I do not understand that.

Uh, "view(dst)" is what I proposed to keep dst mutable, and "mapping(...)"
is also what I proposed to map the intersected part (like inner join in
relational DB), "_1 = _2" may be Phoenix, without "eval", the assignments
won't happen.

Although the above can be written as:

    foreach(mapping(view(dst), src, _1 = _2), nop)

But that's not elegant and not works with void-return.

>      * Conversion function 'as_view' to make Container a view to reserve
>>> the
>>>
>>>>
>>>>>  mutability.
>>>>>>
>>>>>>
>>>>>>  You mean to make it immutable?
>>>>>
>>>>>
>>>>
>>>> No, the opposite, to keep the elements mutable as they were.
>>>> Algorithms in Fusion take const&, 'as_view' is mean to workaround.
>>>> Not sure if Fusion will insist on functional-style.
>>>>
>>>>
>>> No, the opposite. I'm thinking about allowing mutable views. Would
>>> you be willing to implement them?
>>>
>>
>>
>> OK,
>> function: view(seq)
>> returns:
>>   if seq is view -> seq
>>   else -> container_view // in detail or public?
>>
>> Or better name suggestions?
>>
>
> No, I meant: I am considering allowing views to be mutable
> by allowing algorithms take const&.
>

The algorithms currently take const&, even for containers, that's why I
need an indirect view to keep the elements mutable.

So what do you mean by "allowing views to be mutable" & "allowing
algorithms take const&" here?

I suggest starting with a clear use case on a problem that can't
> be solved (currently) with Fusion and a clear proposal on a solution.
> It's very possible that I am missing a lot.

FWIW, I adapted GIL pixel as Associative Sequence, trying to find an
effective way to manipulate pixels.

Regards