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

[Talin]

Josiah Carlson wrote:
> 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?

You're missing a crucial point: The whole idea of 'promise', as I 
understand it, is that it works with functions that aren't expecting a 
callable.

For example, you cannot pass a lambda as the second argument of 
dict.setdefault, because setdefault expects the second argument to be 
already evaluated. So if I say:

    a.setdefault( key, lambda a: [] )

...what you will end up with is the value being a reference to the 
lambda function, not the *output* of the lambda function.

A 'promise' on the other hand, doesn't need to be explicitly called to 
evaluate it. Instead, it automatically evaluates itself whenever it is 
'used'. The problem, of course, is that we haven't defined 'used' very 
well. (I.e. if you pass the unevaluated argument to another function, 
does it get evaluated or not?)

Now, I don't have a problem with the -1, except to say that nothing 
concrete has actually been proposed yet, so there's nothing to vote on. 
(Unless you are voting to kill the discussion.)

I'm actually more interested in exploring the general concept of 
deferred evaluation. The ability to control *when* a particular piece of 
code runs is extremely powerful, and in fact can emulate virtually every 
other programming construct, all the way from a simple if statement to 
concurrency and object inheritance. There are dozens of flavors of 
deferred evaluation already in the language, and none of them (IMHO) are 
redundant.

I'm also interested in anything that blurs the line between code and data :)

-- Talin