[Python-ideas] And now for something completely different

[Cliff Wells]

On Fri, 2008-09-19 at 13:14 +1200, Greg Ewing wrote:
> Cliff Wells wrote:
> 
> > I think the overhead of creating a closure would
> > be acceptable provided it only affected this explicitly specified case
> > and not function calls in general.
> 
> The problem is telling which cases are affected. If you can't
> tell until run time, then code has to be generated to handle
> either possible case for all function arguments, which seems
> like an effort out of proportion to the problem being solved.

You should be able to tell at compile-time which functions are affected
(assuming we used a signature indicator.  If a function has *any*
deferred arguments, it is a special type
<function-with-deferred-arguments> rather than plain <function>.

> And there will still be some runtime overhead in selecting
> between the two cases.

It depends on how selection is done already (say for functions vs
methods).  If it's implemented via a type-selected vector then having a
separate type <function-with-deferred-arguments> then the overhead would
be nil.  If it requires explicit testing, then there would be at least a
small overhead.

> The only way I could see this working is if deferred arguments
> are marked at *both* the calling and called sites. Then the
> compiler knows what code to generate, and the called function
> can check that it has been passed the right kind of argument.

Actually, that might just be acceptable (if not my preferred form).  It
meets my desire to enforce lazy evaluation although it retains the ugly
lambda in the caller.  

Cliff