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

[Alexander Belopolsky]

Josiah Carlson <jcarlson <at> uci.edu> writes:

> 
> 
> Talin <talin <at> acm.org> wrote:
> > 
> > I want to take a stab at unifying a number of ideas that have been 
> > proposed recently:
> 
> 1. It's either a strange way of spelling lambda, and doesn't gain
> anything except a reduction in typing by 1 character.
> 2. Or it's a strange way of deferring evaluation of a line in the
> current stackframe.

My understanding of Talin's proposal is that it is # 2 above. I don't see
anything strange about this idea.  In fact the S family of languages (S,
S-plus, R) defers evaluation of function arguments by default.  This
feature has some interesting concequences, for example R's plot function
can put "y" on the label when invoked as plot(y).

I don't think python needs any syntactic sugar to support this feature.
One can emulate R's lazy evaluation by implementing a "promise" class that
contains slots for a callable and a result that is filled on demand.

Something along the following lines:


class promise(object):
   def __init__(self, callable):
      self._callable = callable
      self._result = None
      
   def __getattribute__(self, name):
      attr = object.__getattribute__
      if attr(self, '_result') is None:
          self._result = attr(self, '_callable')()
      return attr(attr(self, '_result'), name)

def f(x):
    print x.values()

f(promise(lambda: {1:2,3:4}))
-> [2, 4]

Similarly, one can write "promise_number", "promise_sequence" etc. classes
that will dispatch the appropriate special methods to a lazily evaluated
object.  Once type annotations are in-place, it may even become possible
to spell such classes "promise[interface]" and automate their creation.
I think this is a valuable use case for the future type annotation
discussions.