On Tue, Jul 22, 2008 at 8:45 AM, Zeljko Vrba <zvrba@ifi.uio.no> wrote:
On Mon, Jul 21, 2008 at 07:08:15PM +0200, Istvan Buki wrote:
>
> Here is a small example that read data from a CSV file, filter out a column
> and write the result to another CSV file.
>

>
> struct AddressBook
> {
>   typedef fusion::map <
>     fusion::pair< fields::first_name::type, fields::first_name::value_type
> >,
>     fusion::pair< fields::last_name::type, fields::last_name::value_type >,
>     fusion::pair< fields::age::type, fields::age::value_type >,
>     fusion::pair< fields::address::type, fields::address::value_type >,
>     fusion::pair< fields::postal_code::type, fields::postal_code::value_type
> >
>   > type ;
> } ;
>
Hm, this looks like a lot of duplication and grunt work.  I wonder whether MPL
or fusion could be used to generate the above given just the type list:

<first_name, last_name, age, address, postal_code>

(because the pattern is very regular.. each type expands to two types (base
type suffixed by ::type and ::value_type), wrapped in fusion::pair,
concatenated into a list handed over to fusion::map>)

Yes, indeed, it is lot of "not so interesting" code to write and MPL could probably come to the rescue here.
However, at this point I did not want to work on that because I don't know in which direction my tool will evolve. One of the ideas I have in mind is to create a small GUI that would allow creating the data flow by placing symbols on the window and connecting them with arrows. Then the GUI would generate the corresponding fusion maps, the components, the connections,... and finally call the compiler to create an executable. I'm far from that goal but as you can see I've plenty of crazy ideas ;-)


>
> {
>   metl::csv_istream< AddressBook >::impl in_file( "addrbook.csv" ) ;
>
>   typedef metl::filter< AddressBook, fields::age >::impl filter_t ;  //
> remove the 'age' column
>
>   typedef metl::result_of::filter< AddressBook, fields::age >
> filter_result_t ;
>
Why do you have to use metl::result_of?  Wouldn't it be simpler to have a
result typedef inside the filter? ('typedef filter_t::result filter_result_t')

Again, this  started as a fusion learning experiment and I decided to use the same convention as fusion to construct the result types.
I admit it is not clear to me what reason decided the fusion developers to use the result_of namespace instead of a typedef inside the algorithm classes.
 

Thanks for the example, a while back I did something similar:
http://zvrba.net/software/data_stream_toolkit.html

The code was used to process huge amounts of data, but it was at the same time
my own experiment with "declarative programming" in C++.  I wanted to extend
the toolkit to be able to reuse the same "declarative computation" at several
places without actually redoing the computation several times, but that
required storing the functors into variables of unwieldy types..  I also tried
experimenting with Phoenix-2 at that time, but it was too difficult (my first
experience with megabyte-sized messages from the compiler.)  So I ended up with
my own conventions for argument and result-types and coding something less
general that fullfiled my needs at that time.

I'd like to extend the above idea to something like a "subset of SQL in C++",
but.. that'll have to wait better times :-(


Thanks for the link. It looks very interesting and shows that there are many ways to solve the same kind of problems. I hope you will find the time to extend it as you wish.