[boost] Re: Lambda Library.

From: Jaakko Järvi (jaakko.jarvi_at_[hidden])
Date: 2000-03-13 07:52:18

Hi,

dave abrahams <abraham-_at_[hidden]> wrote: 
> The things I can find to criticize so far are:

First, thank you for your thorough comments. I'll respond to the ones
that maybe need some clarification. 

> 1. It's a little disturbing that you can write 'obvious' things which
> compile and 'should' work, but fail only at runtime, e.g.
> > for_each(a.begin(),a.end(), cout << ", " << free1); //valid, but
wrong
> > for_each(a.begin(),a.end(), cout << constant(", ") << free1); //ok
> 
> Incidentally, wy doesn't the first one work, if your example
"free1+5" does
> work? How does the user know when she must write constant.

The reason is simple. As the implementation is based on operator
overloading, at least one argument of an operator invocation must be a
free variable (or another lambda expression).
Hence, in 

  cout << ", " << free1 

cout << ", " is evaluated first (it outputs ", ") and returns cout. 
Then cout << free1 is evaluated, which creates a lambda function.

> 2. Naming: It's best to avoid abbreviations, so I don't like 'var'. I
think
> 'argument' would be much more descriptive than 'free'. 'create_ptr'
doesn't
> create a pointer, it creates an object on the heap (maybe
'new_object')

I (and Gary as well) agree. The names could be better. We have changed
them back and forth, and couldn't always find a satisfactory result. 
Opinions and suggestions are appreciated.

'new_object' might be better than 'create_ptr'
An alternative for 'var' and 'constant' might be 'defer_variable',
'defer_constant'. What do you think?
'free' is just something we picked up. It's however easy to define new
placeholders, so a programmer is free to use whatever names (s)he
prefers.

LL_NAMESPACE::free1_type argument1
LL_NAMESPACE::free2_type argument2

> > The delayed variables and constants can be defined outside the
labmda
> > expression as well:
> 
> Why would anyone want to write it that way? It's much harder to read
than
> the original.

If the lambda expression is very long and complicated and refers
several time to a delayed variable. That was the idea behind providing
var_type

> Incidentally, aren't there some parens missing around the suboordinate
> clauses of the while_loop?

Oops... Thank you.

> 4. I would think a lambda version of ?: would be more important than
> if_then_else... how 'bout it?

Good idea. We'll add one.

Thanks again for your comments. 

/Jaakko