Lambda the Ultimate

Generators certainly can be easier to understand than continuations, but I do think the implementation in Python is taking the wrong direction. I think they're better off getting real closures and then implementing generators via closures (perhaps with some sugar) than implementing a separate generator type which requires special handling in the runtime. After all, speed is not an essential concern in Python.

This is also how I'd implement it in Lisp - a standard library built on closures or continuations with standard sugar to express the common patterns. Except in Lisp sugar is first class (kinda, but you know what I mean I hope!)

Isn't the closure passing technique inefficient?

"However, recent experience with C and C++ has finally revealed the source of my cognitive dissonance--these languages lack the ability to write and use simple mapping functions like Lisp's mapcar! In particular, while C and C++ offer the ability to pass a function as an argument to another function (i.e., a "funarg"), the functions being passed cannot contain references to variables of intermediate scope (i.e., the functions are not function closures), and therefore they are essentially useless for most mapping processes."

That is not the case. It is easy and straightforward to apply a function -- moreover, a closure -- to all or particular elements of a collection. It was easy in C++ version 2, it is especially easy now, with templated functions. Many STL algorithms (e.g., find, search, etc.) take a predicate, which is often a closure. A LinAlg package http://pobox.com/~oleg/ftp/LinAlg.README.txt has allowed you to write

 void foo(Matrix& m, Matrix& m1)
 {
  class ApplyFunction : public ElementWiseAction
  {
    double (*func)(const double x);
    void  operator () (REAL& element) { element = func(element); }
    public: ApplyFunction(double (*_func)(const double x)) : func(_func) {}
  };
  to_every(m).apply(ApplyFunction(sin));
  to_every(m1).apply(ApplyFunction(cos));
 }

     to_every(MatrixDiag(m)) += 1;

     to_every(MatrixRow(m,1)) *= of_every(ConstMatrixColumn(m1,2));

multiplies every element of the first row of m by the corresponding element of the second column of m1. The latter operations are highly efficient. LinAlg also offers more conventional "iterators" (various matrix streams: row streams, column streams, block streams). LinAlg even supports lazy matrices.

Problems begin when what you want is an active iterator (some way to control when a new element is returned). The conventional OOP solution is to have some kind of Iterator object, which essentialy stores the position inside the collection. This, though cumbersome, is doable. But using this approach on more complicated data structure (i.e., trees) can be quite difficult. Without solving this issue you are stuck, and can't implement recursive traversal algorithms.

A less important problem is, of course, the lack of anonymous functions, which forces you to declare countless functions (your example overlooked this, by using sin and cos). For example simply incerementing each element in a collection, will force you to write an inc function.

<aside>Consider: In Ada/C you must define new routines; in Scheme you have anonymous functions; in Haskell/J you can specialize existing routines (1+) "fixes" one of the arguments of +. </aside>

Matrix m(-1,rsize-2,2,csize+1);
struct filler : public ElementWiseAction {
double counter; const double incr;
void operator () (REAL& element)
	        { element = counter; counter += incr; }
filler(const double _init_val,const double _incr) :
counter(_init_val), incr(_incr) {}
};
to_every(m).apply(filler(pattern,incr));
assert( of_every(m).max_abs() == 
pattern + incr*(m.q_no_elems()-1) );

A less important problem is, of course, the lack of anonymous functions, which forces you to declare countless functions (your example overlooked this, by using sin and cos). For example simply incerementing each element in a collection, will force you to write an inc function.

Not necessarily. Consider the following snippet:

       MakeTestFunction("x^3 - 2*x - 5, from the Forsythe book",
         Lambda((const double x),double,
     	   return (sqr(x)-2)*x - 5))().
         run(2.0,3.0,2.0945514815);

http://pobox.com/~oleg/ftp/c++-digest/Functional-Cpp.html http://pobox.com/~oleg/ftp/c++-digest/Lambda-CPP-more.html

This is only way way of introducing lambda abstractions into C++.

In Haskell/J you can specialize existing routines (1+) "fixes" one of the arguments of +

You can do similar things in C++. STL has a whole bunch of adapters -- such as bind1st, bind2nd. So, for example, you can write

	find_first_of(begin,end,bind2nd(less,5));

Brian McNamara and Yannis Smaragdakis have been developing FC++, http://www.cc.gatech.edu/~yannis/fc++/. They have managed to implement most of the Haskell prelude, in C++.

Neither this nor previous message attempted to make any value judgement.

We mentioned FC++ and other similar libraries in the past. The technqiues are nice to know about, but I think the jury is still out on their practical usefulness.

The STL did do a great job by introducing function objects etc.

I might mention that you can do most of this in other OOP languages, but you may encounter interesting difficulties.

In Ada for example, you have to wrestle with type scoping rules that are meant to prevent memory leacks. This can be quite bothersome. A less important issue is that yuo can't overload the function calling operator ().

Still, one has to remember that all these things are awkward in languages that don't allow nesting of routines. At least Ada allows you to do that (as oppsoed to C).

Now what about some value judgements?