Re: [boost] [Fusion] Some ideas

Subject: Re: [boost] [Fusion] Some ideas
From: TONGARI (tongari95_at_[hidden])
Date: 2013-02-03 11:39:25

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

> On 2/3/13 11:24 PM, TONGARI wrote:
>
>> 2013/2/3 Joel de Guzman <djowel_at_[hidden]>
>>
>> On 2/3/13 9:59 PM, TONGARI wrote:
>>>
>>> Just uploaded to:
>>>>
>>>> https://github.com/jamboree/****Boost.FusionEx
>

>>>> <https://github.**com/jamboree/Boost.FusionEx
>
>>>> >
>>>>
>>>>
>>>> There are:
>>>> + mapping
>>>> + left_mapping
>>>> + full_mapping
>>>>
>>>> Simple tests contained.
>>>> Comments/improvements are welcome :^)
>>>>
>>>>
>>> By looking at the sample code, it seems I misunderstood your original
>>> post by a long shot.
>>>
>>
>>
>> How did you understand it then?
>>
>
> I guess it's irrelevant how I understood it then. What's important is
> how I can understand it now and I really want to understand what it
> is exactly you are trying to achieve.
>
>
> There's a bit different than what I originally wrote.
>>
>> The first thought was to map-assign the data:
>>
>>      mapping(dst, src)
>>
>> And now it's more general:
>>
>>      result = mapping(a, b, binary_op_on_data)
>>
>
> Good idea. But it's better if you can provide both versions.
> Something similar to filter and filter_if.

I don't see how they related. The original one gives an immediate result,
while the later is lazily evaluated. filter & filter_if are both lazily
evaluated.
Are you suggesting a shorthand for mapping(a, b, _2)?

> returns a view which is also associative
>>
>> FWIW, "mapping/left_mapping/full_**mapping" are analog to "inner
>> join/left join/full join" in relational DB.
>>
>
> Perhaps mapping is not a good name? Then of course, we already
> have "join".

Well, I don't have a better one, do you?

> I still don't understand "view" and "eval" enough. Pardon me for
> being slow. It would be best to collect all your thoughts in a single,
> complete explanation of all these new additions so that we don't
> have any misunderstandings.

Maybe I have to implement all these to show what they really are...
But I'll try to explain with a simple use-case here:

Given:

    vector<int, string, int> v;

How would you assign to the ints in v?

    foreach(filter<int>(v), _1 = 99);

Will that compile? No, you can't assign to read-only value.
Why are they read-only? Because filter<int>(v) takes v as 'const&', there's
no '&' overload.

So how could I do?
Make something that takes v by reference, and that's what 'view' is for,
and this time

    foreach(filter<int>(view(v)), _1 = 99);

would work.

BTW, algorithms in GIL only work for Views, while Fusion takes both
Sequence & View, I think it's a good idea to only accept View, but this is
not the way that fusion was designed.

Regards