Re: [boost] [Boost.Lambda] Some new features are suggested: return, iterating yield, & local var

Subject: Re: [boost] [Boost.Lambda] Some new features are suggested: return, iterating yield, & local var
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2012-01-04 10:00:41

Hi Huang,

On 01/04/2012 05:05 AM, Huang Huan wrote:
> Yes, Boost.Phoenix do a lot forward in unname function.
> Unfortunately the presented features are not found in it.
>
> 2012/1/4 Mathias Gaunard<mathias.gaunard_at_[hidden]>
>> return is hard to implement, since each expression is building its own
> expression, so you need to forward it along the whole chain.
>> Exceptions could also be used, but it's not very nice.
>
> return is the most usefull part of function. I'm working on the implement,
> it's approved work with no exception for return. The architect is defferent
> from the lambda, I think the phoenix is also .
> The final functional call is wrapped, and create a heap/stack like
> workspace. It will support restore for yielding calls.
> and yielding&  local var are also involved in the return architect.

I agree, "return" is very useful when you want to stay as close to C++ 
as possible.
However, returning a value is highly unusual in functional programming 
and if there is something like returning something it is implemented as 
a Monad.
Additionally i found it overly complex to implement a return statement. 
It would require deep introspection of the expression at hand to check 
if there is a return statement inside the expression to calculate the 
return type. Additionally, it is rather hard to deal with diverging 
return types (though a variant could be used here) or to output 
meaningful error messages (something which i would like to focus on in 
the next releases).
Please note that I am not saying it is impossible to do that with 
phoenix, quite the contrary.

>> Boost.Phoenix provides local variables using let/in syntax.
>
> let(_a = 1)[...]
> I think the let syntx is a worse way, and you may make some mistak of my
> way. The let syntx is quite different from the C++ style, and _a ... _z are
> limited.

The let syntax was chosen to mimic the style of traditional functional 
programming languages. Which is in contrast to the initial advertisement 
of phoenix stating it is "C++ in C++". In fact, the scope module is 
probably the place where Phoenix differs the most from traditional C++ 
syntax. Mainly due to the fact that things like this weren't really 
possible in C++ when Phoenix was invented. Joel might have some more 
insight on his motivation to chose that syntax!
_a to _z are just some predefined local variable names. You can define 
your own names, with your own tags.

> I have implement the major part of my way, and some syntax have changed as
> below:
>
> // this macro is define in the lib define, use local_var_name<int id>
> #define var_name(x)  local_var_name<__LINE__>   x;
> // example begin here
> struct A {
>      A() {};
>      A(char ch) {};
> };
>
> var_name(x); // just predefine the name in no type for lambda using.
> var_name(y); // one single line for one var_name, the macro could be
> redefined add some unuse code for unique line protect.
> var_name(z);
> (
>      (
>          // declaring use local_var, scope begin here
>          local_var<A>  (x) ,        // default construct   A::A()
>          local_var<A>  (y) ('a') ,  // construct<A>('a')   A::A(char)
>          local_var<A>  (z) (x) ,   // copy construct      A::A(A const&)
>          x = y                         // assignment
> A::operator=(A const&)
>      ),
>      (
>          x,y,z,                       // error, out of scope
>      )
> )
> p.s.
> 1. the phoenix omitted the different way of construct/copy/assignment.
> 2. free style identifier name, better for code reader.
>

Your described syntax isn't that different from Pheonix.
Phoenix supports the copy constructor and assignment operator. 
Additionally, Phoenix provides construct<A> which can be used to create 
instances of objects.
However, I agree, that having a "free style identifier" name would 
greatly improve Phoenix.

>
> Actually I have rewrote lambda, it support return/yielding, most operators,
> part of local var, without bind. I want to join the dev of Boost.Phoenix,
> if can how?

I am one of the authors, Joel de Guzman is the main author and inventor 
of Phoenix.
Patches and ideas are always welcome!

Best Regards,
Thomas