> I think implementing reordering in fusion::map and fusion::set is not a
> good idea. At any rate reordering per se does increase compile time and
> does not fit to the underlying concept of random access (sequence).
> On the other hand, reordering via fusion::nview is simple. I think it
> might be a good idea to get this documented, as an example maybe, or in
> a "useful bits&pieces"-section.
Thanks Christopher; however, I must be misunderstanding what Alfredo
wanted. I just thought he wanted named parameters. I thought the
example he gave:
yes, I wanted named parameters but not just to call the function, but also to define functionals (I think in C++ called higher order function).
The example of the derivative with respect to one parameter is an example of a funtional (because the derivative at a point is a funcion of the function).
I just wanted to stress that the parameter name should be know not only by the used but also by other parts of the program.
I think that request complicates things a little bit the things. Although after reading Dave message I might be wrong and it is just more of the same.
> One question: Why I can not interchange the order of p and q in the
> last call, after all it is a map at the library could in principle
> differentiate the pairs? making it possible to call an unordered named
> parameter. e.g.
> cout << H(
> map<pair<p, double>, pair<q, double> >(
> make_pair<q>(2.), // was p
> make_pair<p>(1.) // was q
> )
> );
in his OP illustrated that, and I thought my last code example
did just that:
typedef
map_default
< mpl::pair<mpl::int_<1>,ti<1> >
, mpl::pair<mpl::int_<2>,ti<2> >
, mpl::pair<mpl::int_<3>,ti<3> >
>
map_def_ti1_3_t;
...
map_def_ti1_3_t
map_def_ti1_3_val2_1
( fusion::pair<mpl::int_<2>,ti<2> >(2)
, fusion::pair<mpl::int_<1>,ti<1> >(1)
);
What am I missing?
Hi Larry,
thank you for your work. I didn't understand the code with the "map_def_ti1_3_t;", etc code, but I think you achieved arbitrary named parameter ordering with it.
But the free_at.hpp example is almost exactly what I was looking for, except that instead of using an integer for defining the "free" (only not bound) parameter I wanted to use a name (fusion map key). So I adapted your free_at.hpp to use fusion::map instead of fusion::vector but the code is very similar, I will post it here once it is finished. I think the map implementation is more general because potentially the map elements can be addressed by positional index also.
Originally I was thinking in a very complicated way to do this by defining a bind function with all the non free parameters specified and then operator() with the free parameter. But given the application I am looking for, the free_at is not part of the interface but some internal temporary representation and since the value of the free parameter is actually used (to take the derivative at the end), your implementation is the perfect shortcut, small code easy to understand, it is genius.
I guess I was too demanding at wanting all the notational flexibility all at once. I think it is still an interesting question. I just hope that in the future boost::fusion gets incorporated as part of the language in some way. After all Larry's example was all about converting variadic templates into fusion sequences. I think that what fusion does is so fundamental that it should be part of the language. That would be so cool.
Thanks very much,
Alfredo
(PS: I hope the discussion continues, these things are very interesting. I think a language is ALL about notation, so what ever increases the expressiveness should be welcome).