Language Design Is Not Just Solving Puzzles ist ein recht interessanter Artikel von Guido van Rossum über die Unmöglichkeit einer eleganten Syntax für mehrzeilige Lambdas in Python. Lesenswert und in weiten Teilen stimme ich ihm zu. Allerdings stolpere ich dann über so einen letzten Absatz:
And there's the rub: there's no way to make a Rube Goldberg language feature appear simple. Features of a programming language, whether syntactic or semantic, are all part of the language's user interface. And a user interface can handle only so much complexity or it becomes unusable. This is also the reason why Python will never have continuations, and even why I'm uninterested in optimizing tail recursion. But that's for another installment.
Ich bin durchaus bereit zu akzeptieren das Continuations komplex sind - aber nicht wegen des Interfaces. Denn im Interface für Continuations braucht man nur den callcc Aufruf zum Binden der Continuation und eine einfache Funktionssyntax zum Auslösen der Continuation. Das Hauptproblem bei Continuations liegt in der Kooperation mit Generatoren und Exceptions - was passiert, wenn eine Continuation innerhalb eines Generators ausgelöst wird? Was passiert, wenn innerhalb einer Continuation eine Exception ausgelöst wird? Das sind die schwierigen Aspekte - die übrigens auch Scheme-Implementatoren zum Schwitzen bringen, weshalb bei denen in der Regel Exceptions nicht so gerne gesehen werden (gleiches Problem, einfach nur aus der anderen Richtung betrachtet).
Also ok, keine Continuations in Python - auch wenn wir schon längst poor-mans-continuations mit pickable generators bekommen (oder mit Greenlets, oder mit cloneable Coroutines, oder einer der anderen vielen Ansätze um Subsets von Continuation-Features zu erhalten).
Aber was bitte schön ist komplex an Tail-Call-Optimization (denn es geht nicht nur um Tail-Recursion)? Die ist so primitiv, das sie transparent für den Programmierer implementiert werden kann - wenn ein Tailcall vorliegt, keine Rücksprungadresse auf dem Stack notieren, sondern die Parameter im Stackframe umladen und einen einfachen Jump notieren. Wenn man nett sein will, kann man noch eine Pseudofunktion "tailcall" einführen, welche eine Exception auslöst wenn sie nicht in einer Tailcall-Position ausgeführt werden soll. Es mag weitere Bedingungen geben, unter denen Tailcalls nicht optimiert werden können - aber diese können genauso in eine entsprechende Prüfung einfließen.
Gerade der Funktions-Overhead ist es ja, der manche Algorithmen in Scriptsprachen nur unschön implementierbar macht. Und Tail-Call-Optimization würde da definitiv helfen. Ganz besonders in Situationen, in denen man eine Kette von kleinen Funktionsaufrufen hat. Wegen meiner kann es auch gerne eine Optimierung sein, die nur bei -O (oder einem -O2 oder sonstwas) aktiviert wird.