[boost] Re: Lambda Library.

From: Dave Abrahams (abrahams_at_[hidden])
Date: 2000-03-14 00:04:24

on 3/13/00 7:52 AM, Jaakko Järvi at jaakko.jarvi_at_[hidden] wrote:

> 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.

And now that I look at it, it's obvious to me what's happening. Damn, that's
a thorny one. I wish there were a way to handle this in general. Maybe the
best thing you can do is to make it clearer in the documentation, though I'm
not particularly satisfied with this approach.

Okay, now here's a stupid C++ trick to consider. Could you make this syntax
work?

lambda/ cout << ", " << free1

> 'new_object' might be better than 'create_ptr'
> An alternative for 'var' and 'constant' might be 'defer_variable',
> 'defer_constant'. What do you think?

I think they're too long (that's right, I'm never satisfied).

> '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

Yeah, but boost::free1 sounds like a memory deallocation function. I really
would like the defaults to be better names. I'd even make a concession to
abbreviation if we could use boost::arg1 (I do see the value of short names
for these).

>>> 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

Okay, then this is something to clarify in the documentation. Is there a
runtime cost to writing variable(i) multiple times, or are you just worried
about the amount of typing here (if the latter, I'd just stick with
variable(i) personally - the idea of this lib is ease of use, right?)

-D