[Python-3000] Wild idea: Deferred Evaluation & Implicit Lambda

[Josiah Carlson]

Alexander Belopolsky <alexander.belopolsky at gmail.com> wrote:
> 
> On May 30, 2006, at 8:52 PM, Josiah Carlson wrote:
> >
> > Really, this boils down to another way of spelling lambda.
> >
> 
> I almost agree.  The difference between a promise and a lambda is  
> that the former can be passed to functions that don't know how to  
> deal with callables.  I think an appropriate analogy is the  
> difference between a pointer and reference in C++.  In C++ references  
> are logically equivalent to (const) pointers, but are not  
> interchangeable within the type system. There may be the same reason  
> to add promises to python as Stroustrup had for adding references to C 
> ++: operator overloading <http://www.research.att.com/~bs/ 
> bs_faq2.html#pointers-and-references>. A function def foo(x,y):  
> return x+y will work fine with x or y or both passed as instances of  
> promise[Number], but will not work if either is a lambda.
[snip]

It's all a matter of semantics.  If I tell you "I'm going to implement
deferred/promise/etc., as a callable", and as long as I tell you the
semantics of that call, it will be clear what I mean.  Let's actually go
through the trouble of defining it:

If I call something a "future", a "promise", or a "deferred", what I
mean is that the actual evaluation of an arbitrary sequence of
statements and/or expressions will be "deferred" to the "future" and
that I "promise" to evaluate them if given the proper opportunity.  How
I will define such a thing is to say that any callable that takes zero
arguments is a "future", a "promise", or a "deferred", and that calling
this callable without any arguments will evaluate the specified
statements and/or expressions.

Now that I have sufficiently specified, please explain to me how a new
syntax would improve the current situation?

 - Josiah