Subject: Re: [boost] Reimplementation of the MPL for C++11
From: Louis Dionne (ldionne.2_at_[hidden])
Date: 2013-10-20 13:19:41
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