[boost] Re: Lambda Library.

From: Gary Powell (Gary.Powell_at_[hidden])
Date: 2000-03-13 12:23:27

Hi,

> Having looked at the documentation, but not the code, I think this is
> beautiful work. 
Thank you!
> If I thought this could have been carried to a conclusion
> anywhere nearly this satisfactory I would have pursued it myself months
> ago.
I started work on this last year, it was only in January that I met up with
Jaakko and his BL library and that has made all the difference.

> The things I can find to criticize so far are:
> 
> 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()?
> 
I can see that this will need some getting used to. Expression templates
will try to do things once. For evaluating constants this is what you would
want.

int x, y;
...
transform(a.begin, a.end(), x + y + free1);
will make a temporary of x+y and add the result of that to the argument of
a.

> 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'?)
Ok, new_object would be fine with me.
var, is a little harder for me because if you have to write the fully
qualified name everywhere its going to be hard to read and understand.

for_each(a.begin(), a.end(), boost::ll::variable(x) = boost::ll::argument1,
                             boost::ll::argument1 = boost::ll::varible(y),
                             boost::ll::variable(y) = boost::ll::variable(x)
);

line breaks help but....

> 3. Documentation. You've done a remarkably thorough job of documenting
> this,
> especially for an alpha release, 
> 
Thank you,

> but:
>  a. I'd like to see you qualify all names with their respective
> namespaces.
> That will give a much better picture of how it would look in real,
> best-practices C++ code.
> 
Ok, but I never use that style in my real work except in files which have
name collisions. IMO it makes it too hard to read.

>  b. Occasionally, you reveal implementation details which only seem to
> confuse the issues, without giving the user additional expressive power:
> 
> > int i = 0; 
> > int j;
> > for_each(a.begin(),a.end(), (var(j) = free1, free1 = var(i), var(i) =
> > var(j)));  
> >
> > The delayed variables and constants can be defined outside the labmda
> > expression as well:
> > int i = 0; int j;
> > var_type<int>::type vi(var(i)), vj(var(j));
> > for_each(a.begin(),a.end(), (vj = free1, free1 = vi, vi = vj));
> > 
> > constant_type<int>::type five(constant(5));
> > for_each(a.begin(),a.end(), (vi = five, free1 = vi * constant(6) ));
> 
> 
> Why would anyone want to write it that way? It's much harder to read than
> the original.
> 
> 
> Your control-flow examples could benefit from some well-chosen line
> breaks:
ok,

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

> 4. I would think a lambda version of ?: would be more important than
> if_then_else... how 'bout it?
Sorry, can't overload ?:, in fact overloading new, delete, -> and ->* don't
work either because they have a defined return type, which is not what you
want in this case.

Thanks again for all the comments.

  -gary-