Alexander Belopolsky <[EMAIL PROTECTED]> 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 _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
