Kirit Sælensminde wrote:
Of course, Egg supports also:
typedef boost::result_of<T_curry2(int(*)(int,int))>::type T_curried_plus; T_curried_plus curried_plus = curry2(&::plus);
No macros. But there is a function-call, which incurs dynamic-initialization. You might notice that "static form" using macro and "dynamic form" using function is nicely symmetric.
So the macro removed the first function call and actually writes a function which is the curried version rather than perform the currying at runtime? Now that *is* cool and seems to be a good enough reason to have a macro (to me at least)! :)
Egg's ambition is to replace a normal function, which is statically-initialized. Hence, with or without great optimizers, Egg has to offer FunctionObject which is statically-initialized, I think.
There is another Boost library out in 1.35, Boost.FunctionTypes, which might be able to help as it has decomposition functions that work with a wider range of callable function than for example Boost.Function does. Maybe that can be leveraged against? I've not had a chance to delve into it myself yet though, but Tobias Schwinger seemed to think it would handle the higher order requirements I was playing with last time I raised it on the list.
http://thread.gmane.org/gmane.comp.lib.boost.user/30665/focus=30762
With that libray, I could document "When Egg can automagically calculate function arity". I bet clients use "numbered-form function" before they try to read my complex document, though. FWIW, Egg works with PolymorphicFunctionObject, which is virtually standardized by tr1 result_of. Regards, -- Shunsuke Sogame