Abel Sinkovics <abel <at> elte.hu> writes:
1) I can see that you have this syntax for if_:
if_<CONDITION, THEN>:: else_if<CONDITION, THEN>:: ... else<ELSE>
which is I think a great DSL for the if structure. Can this be used in a lambda expression? For example:
Yes, you can use it with lambda expressions. This one took a lot of work to get working, though :-).
2) Metafunctions could support lazy evaluation. This makes it possible to use lazy evaluation strategy in metaprograms which makes the code easier to read. (Even for a factorial or Fibonacci there are huge differences)
I'm aware of this and I'm currently searching for a general solution. I think I might have a very elegant solution for this; I'll provide an update when/if I get it working.
3) Naming the lambda arguments _1, _2, ... has limitations. When you use lambda inside lambda, you can not refer to the arguments of the outer lambda from the inner one. I have built a lambda implementation where you can give the arguments names and use that instead of the MPL one.
Yes, I'm aware of this. I'm currently working on let-expressions. I'm also working on generalized placeholders: they can perform arbitrary computations and return sequences of types so that it's possible to use LambdaExpressions with variadic parameter packs. Example: mpl11::apply<your_metafunction<mpl11::_args>, ParameterPack...> The obvious extension to this is to have placeholders like mpl11::_args<i, j> which returns the arguments in the range [i, j). This is a work in progress.
You can read about my lambda implementation here: http://abel.web.elte.hu/mpllibs/metamonad/manual.html#lambda-expressions It is based on syntaxes and variables, which are described earlier on that page.
I'll definitely have a look at this, thanks for the pointer!
This problem can also be solved by using De Brujin indices, but I find using names more readable so I decided to use this in my lambdas.
Same here, I'm not planning on using de Bruijn indices. Regards, Louis Dionne