Re: [boost] [Fusion] Some ideas

Subject: Re: [boost] [Fusion] Some ideas
From: Joel de Guzman (djowel_at_[hidden])
Date: 2013-02-03 03:27:11

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.

>>     * 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&.

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.

Regards,
-- 
Joel de Guzman
http://www.boostpro.com
http://boost-spirit.com