Re: [boost] [Fusion] Some ideas

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

On 2/4/13 12:39 AM, TONGARI wrote:
> 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,

What original one?

> while the later is lazily evaluated.

what later one?

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?

Not sure.

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

Exactly what I was saying in a previous reply. I am considering allowing
mutability (i.e. taking in & arguments). That way, your code above will
work as-is.

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

Let's take this off-line for discussion. Feel free to reply to me
by email.

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