Re: [boost] Reimplementation of the MPL for C++11

Abel Sinkovics writes:

1) I can see that you have this syntax for if_:

if_:: else_if:: ... 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::applympl11::_args, ParameterPack...> The obvious extension to this is to have placeholders like mpl11::_args 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