Python Design Fehler

[pillmuncher]

CL-Implementierungen, die TCO unterstützen, tun dies dagegen ziemlich sicher auf die genannte Weise: Sie werfen zur Laufzeit den Stapelrahmen weg, wenn ein letzter Aufruf stattfindet. Der teure Funktionsaufruf selbst bleibt also, womit ein großer Vorteil der TCO in Haskell oder C verloren geht. Der einzige verbleibende Vorteil der TCO ist dann, dass der Aufrufstapel nicht wächst.

Dieser letzte Vorteil ist es, an dem mir gelegen ist. Dann könnte man bequem Continuation Style Passing verwenden. Ob das ein paar Zyklen mehr braucht, wäre mir egal.

Ich kann gut verstehen, dass man für diesen, in einer Sprache, in der Rekursion nicht zum normalen Idiom gehört, verhältnismäßig kleinen Vorteil nicht den Interpreter verkomplizieren und lesbare Stacktraces zerstören möchte.

Ich kann das auch verstehen. Allerdings könnte man auch fragen, ob die Tatsache, dass Rekursion nicht zum normalen Idiom gehört, nicht vielleicht daran liegt, dass es kein TCO gibt?

Man könnte übrigens auch zB. ein return from Statement o.ä. einführen, dann kann der Compiler dumm bleiben und der Programmierer kann dadurch explizit machen, dass ihm mehr daran gelegen ist, einen Stack Overflow zu vermeiden, als aussagekräftige Stack Traces zu haben.

Edit: Top-Level Definitionen sind in Scheme offenbar statisch, und können zur Laufzeit nicht mehr verändert werden. Mithin kann der Compiler jeden Funktionsaufruf lexikalisch auflösen und mithin statisch binden.

Ich denke, das folgt nicht daraus, da man ja auch Funktionen als Parameter übergeben kann oder lokal definieren kann. TCO sollte auch in solchen Fällen funktionieren. Wie das genau in Scheme geregelt ist, muss ich nachlesen.

[lunar]

@pillmuncher Ich glaube nicht, dass CPS in Python jemals „bequem“ wäre, selbst mit TCO. Dazu fehlt es an vernünftigen Lambdas, syntaktischer Unterstützung, v.a. ein Operator zur Funktionsanwendung, und entsprechenden Bibliotheken, u.a. zur Resourcenverwaltung. Python ist für CPS einfach nicht entworfen.

Ich glaube nicht, dass das Fehlen der TCO Rekursion als Idiom ausschließt. Ich nehme an, dass es eher umgekehrt ist. Python ist einfach keine funktionale Sprache, und bevorzugt Schleifen vor endrekursiven Funktionen. Statt TCO gibt es eben mächtige Iteratoren und Generatoren.

Ein "return from" wäre imho keine gute Idee. Diese Anweisung lädt geradezu ein, Fehler zu machen, e.g. "with foo: return from bar()". Python ist so abstrakt, dass oft nicht unmittelbar klar ist, ob im aktuellen Kontext nach der Rückkehr der Funktion noch Code auf dem Stack ausgeführt wird.

Was Scheme anbelangt: Nun ja, letzte Aufrufe anonymer, lokaler Funktionen, oder übergebener Funktionen sind ja ziemlich offensichtlich keine endrekursiven Aufrufe. Da kann Scheme nur den Stapelrahmen verwerfen (was es sicherlich auch tun wird, TCO funktioniert also).

Ich bezog mich lediglich darauf, dass Scheme endrekursive Aufrufe statisch erkennen, und dann in Sprünge auskompilieren kann, so dass endrekursive Funktionen tatsächlich äquivalent zu Schleifen verwenden kann (was in einer funktionalen Sprache der wesentliche und wichtige Vorteil der TCO ist).

Ich sehe jetzt nicht, warum übergebene Funktionen oder lokale Funktionen TCO widersprechen sollten. Beides sind letztlich nichts anderes als Funktionszeiger.

[Üpsilon]

Ich werf auch mal was in den Raum, was mich an Py nervt:

Man muss immer das self den Klassenmethoden hinterherschmeißen (als Parameter deklarieren), das vergess ich immer. :-/ Aber mir fällt spontan auch nicht ein, wie das besser ginge.

------
Und zur Frage, was ich gerne in Py4 hätte: eine Möglichkeit des "switch-ens", wie man es in den meisten anderen Programmiersprachen machen kann.

-----
EDIT: Ich weiß jez nicht, ob es vlt. etwas zu radikal wäre, aber wenn man die normalen gedingsten Klammern für Codeblöcke nutzen könnte... das wär schon... neee wär doch scheiße aber egal!

[BlackJack]

@Üpsilon: Irgendwie hast Du jetzt an zwei Fronten das selbe Thema aufgemacht. Ich wiederhole es hier trotzdem noch mal kurz: Viele ``switch``\e kann man in Python mit einem Wörterbuch erledigen und einem ``switch`` haftet in einer objektorientierten Programmiersprache auch immer ein „code smell” an.

[Hyperion]

... einem ``switch`` haftet in einer objektorientierten Programmiersprache auch immer ein „code smell” an.

Das vermittel mal einem "User Unkown" bei uu.de ...

[snafu]

... einem ``switch`` haftet in einer objektorientierten Programmiersprache auch immer ein „code smell” an.

Das vermittel mal einem "User Unkown" bei uu.de ...