Lambda abstractions in C++ vs. Scheme

In Scheme:
     (define foo (lambda (a b) (+ a b)))The lambda-expression when evaluated produces the value of a procedural type. The define form binds this value to an identifier foo. Evaluation of an expression
     (foo 1 2)looks up the procedural value bound to this identifier, and applies it.

In C++, precisely the same idea is expressed as

     Lambda((int a, int b), int, return a+b) foo;where

     #define Lambda(args,ret_type,body) \
     class MakeName(__Lambda___) { \
     public: ret_type operator() args { body; } }The Lambda construction creates a procedural type (class). The instantiation operator -- called 'declaration' in plain C -- "binds" this apply-able type to an instance foo. This sounds better in reverse: foo is bound to a value of a procedural type. Or, foo is instantiated as an object of a class that implements a callable interface.

When the compiler processes an application:
     cout << "foo(1,2) is " << foo(1,2) << endl;it looks up the type of foo, finds the procedural class and invokes the appropriate method. The similarity between the two expressions -- in Scheme and C++ -- is almost complete. The major difference is a compile vs. run-time lookup of values and bindings. Optimizing Scheme compilers blur even this difference.

Year by year, popular programming languages get closer and closer to 1975. Keep on truckin'!

>>2
I refer you to Greenspun's 10th rule:

Any sufficiently complicated C/C++ or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.

… including Lisp.

The venerable master Sussman was walking with his student, Anonymous.  Hoping to
prompt the master into a discussion, Anonymous said "Master, I have heard that
objects are a very good thing - is this true?"  Sussman looked pityingly at
his student and replied, "Foolish pupil - objects are merely a poor man's
closures."

  Chastised, Anonymous took his leave from his master and returned to his cell,
intent on studying closures.  He carefully read the entire "Lambda: The
Ultimate..." series of papers and its cousins, and implemented a small
Scheme interpreter with a closure-based object system.  He learned much, and
looked forward to informing his master of his progress.

  On his next walk with Sussman, Anonymous attempted to impress his master by
saying "Master, I have diligently studied the matter, and now understand
that objects are truly a poor man's closures."  Sussman responded by hitting
Anonymous with his stick, saying "When will you learn? Closures are a poor man's
object."  At that moment, Anonymous became enlightened.

>>5
_{I came bricks}.

>>5
more

>>7
I believe it is spelled 66
moar99

>>5
Recursive lambda-expressions

     (define fact (lambda (n) (if (not (positive? n)) 1
                                  (* n (fact (- n 1))))))
Note when the lambda expression itself is being evaluated -- to a procedural value -- an identifier fact it mentions is not bound to anything. The binding occurs afterwards, after the resulting procedural value is used by define. Yet this does not pose any problem: the lambda expression is not being applied yet at this point, it is merely "compiled". When the value of fact is indeed required, it will certainly have been bound.

In C++,

    Lambda((int n),int,
           if( n <= 0 ) return 1; else return n * (*this)(n-1))
    fact;
The above expression takes advantage of the fact that the "current object" can be referred by this within the body of a method. It explores the same kind of a 'lookup delay' as the Scheme expression above. When the body of a method is being compiled, there is no "current object" yet: this is only potentially bound. Later on, when the compiler sees an application of the method, it knows to which object the method is being applied to.

>>5
MASTER

>>5
>>5
i dont get it

>>11
Objects and closures are the same thing, at least according to >>5.

>>12
DRIVE LIKE JEHU

>>9
Needs more proper tail call.