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

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