On 7/10/07, M. David Peterson <[EMAIL PROTECTED]> wrote:
On 7/10/07, Sylvain Hellegouarch <[EMAIL PROTECTED]> wrote: > > > Not to worry :) > However the question stands, will Python support closures (or does it > already via lambda expressions?) Depends on your interpretation of what a closure is. One interpretation is that w ith closures you can, for example, have a series of lambda expressions, evaluate up to a certain point, add a marker, store it, and then continue where you left off at a later date.
just to clarify, it sounds like you may be mistaking terminology here. the elementary structures by which computations can be stored for later continuation are called just that - continuations. closures, on the other hand, are an organization of program state that can be associated with an object - typically to implement static scoping, as was done for python functions and methods around, someone said, python 2.1. i seem to recall that ruby manifests blocks as first class objects, and associates closures with them, as well. (continuations are interesting, but mostly in the abstract - they're not generally of interest for direct use by programmers. they're the mother of all control flow structures - all the others can be expressed and built using them, but they're very low-level - you would hardly ever want to program with them directly. stackless python uses (used?) them as a key means of building the other flow control structures without using the machine (c, in that case) stack, and they enable economies for massive parallelism that most of us don't need (and couldn't handle without major attention). generators provide the means to express much of what programmers practically want in this vein, and the recent refinements to enable use of generators as coroutines (pep 342<http://www.python.org/dev/peps/pep-0342/>) covers most of the rest. how these structures map to parallelism are up to the language implementation. guido has been actively disinterested in incorporating continuations to the python definition, for various reasons, and i don't expect that to change.) i couldn't resist this clarification, and hope i haven't mistaken what you were saying (or, what i'm saying:-). -- ken http://myriadicity.net As per our conversation in IM, this would certainly be one way to move
towards a stackless and thread-free Python diet. ;-) Also, since we're on the subject, one *true test* of Python language interoperability would be to get Kamaelia ( http://kamaelia.org ) to work properly via IronPython. Kamaelia list (Cc'd): Has anyone attempted to get Kamaelia working with IronPython? If I am understanding things correctly, until support for generators are implemented then this would not be possible. Is this understanding correct? To the IronPython team: Having the ability to run Kamaelia (a brainchild of Michael Sparks of BBC Research) via IronPython would be an absolute dream come true. *AMAZING* potential existing bridging together Kamaelia and .NET, in my own opinion. -- /M:D M. David Peterson http://mdavid.name | http://www.oreillynet.com/pub/au/2354 | http://dev.aol.com/blog/3155 _______________________________________________ users mailing list [email protected] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
_______________________________________________ users mailing list [email protected] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
