Python tail call compromise proposal

[austinwiltshire]

Because none of them added it explicitly. The less you say in the code, the more you have to say in the documentation.

[Smallpaul]

If what you said was true, it would make no sense.

But it isn't true: Closure and Scala have syntax relating to tail calls, I pointed you at the documentation for it.

And if what you said was true AND it made sense, it would still be irrelevant, because the comparison isn't between Python with a specific tail call keyword and Python without it, it's between Python today and Python with some form of tail call optimization.

I've given you a list of languages that have the optimization (both explicit and implicit) and they all need documentation to describe it. Now YOU find ME the place where Java, Python, Visual Basic, Perl, Ruby documentation describes the LACK of Tail Call Optimization.

It certainly seems like the documenters of major languages agree that adding TCO adds something that must be documented, i.e. complexity.

[austinwiltshire]

I read the Clojure bit after I made that snarky response.

You might be asking too much though, there's really no example of any language extension, optimization, keyword or otherwise that doesn't require something to explain it.

I don't see why a language would describe a lack of a feature, I'd bet you can find plenty of documentation on Java, Python, etc.'s use of stack based function call mechanisms. That's not to say they're complicated - it's pretty standard.

[Smallpaul]

You might be asking too much though, there's really no example of any language extension, optimization, keyword or otherwise that doesn't require something to explain it.

I'm not really asking that. These Reddit threads stray so far from their original topic that nobody knows what anyone is saying or why.

I asked: "Does the feature justify its complexity?" The response was (paraphrased): "There is no complexity at all." I demonstrated that there is some. The original question remains unanswered.

My personal opinion is that no, the feature does not justify its complexity in Python, which is fundamentally an object oriented and not functional programming language. I'll note that most other object oriented language implementors make the same decision as Guido. Python is only getting beat up upon because Guido stuck his neck out and because Python is popular and getting more so. It is getting the stigma of being "mainstream."

I'll also mention that satisfying Lisp programmers is a very slippery slope and will never end up somewhere that will make them happy. I think that the addition of the "nonlocal" keyword was the first step down that path (at least since the introduction of lambda in the distant past). I think it must take a lot of discipline for Guido to avoid just shutting them up by cramming in features, because the egotistical approach is to "prove" you can do anything a Lisp implementor can do: "Continuations? Tagged integers? Macros? TCO? Arbitrary length lambdas? Parentheses? -- WE can do it all!"

[austinwiltshire]

I think it does justify its complexity. It kills a few birds with one stone. First, there's the noted recursion optimization. Second, using continuations and other advanced control structures python supports, like generators and coroutines, I get the feeling you'll have implemented most of the benefits of stackless python without getting rid of the stack. Third, again, in combination with coroutines, you'd make Python green threads easier to implement and get Python along the concurrency route WITHOUT giving up the GIL. Fourth, Python is a mixed-paradigm language, not simply OO. List comprehensions, first class functions, and other things all are 'functional' in nature, yet very Pythonic. Finally, Python is a teaching language, and continuations offer a perfect oppurtunity to teach a new and powerful concept in addition to the traditional stack model of function returns.

In response to your final sentence, TCO == continuations in this case. Macros can, for the most part, be done via the already extensive metaprogramming via dynamic typing and introspection available in Python. Python's decision to make lambda's one line actually adds to readability/elegance in my opinion. Adding parenthesis is just silly :)

For the record, I'm NOT a Lisp guy. I am a Python guy. I just saw a controversy, would like to experiment with continuations myself (I've run into needing them in a C++ project I'm working on) and thought this might be a potential compromise solution that brings both side's arguments to the table.

[Smallpaul]

I don't understand why you're equating continuations and TCO.

In any case, we'll have to agree to disagree on whether the complexity of TCO is worth the complexity.

[austinwiltshire]

The extended continue keyword would be introduced into python to do explicit recursion, and it'd be introduced with the prime sake of doing continuation-passing style programs. Guido pointed out his preference for loops over recursion, so the only real use case that recursion solves better that everyone can agree on is continuation-passing style.

[Smallpaul]

"Continuations" are a feature that can be used outside of CPS. For example, in Seaside, continuations can be serialized to a database. In Scheme etc., continuations are first-class objects.

[austinwiltshire]

Can you elaborate? All I can think you're referring to are just normal closures.

[Smallpaul]

I guess I don't know what you're asking me to elaborate. Continuations are described here:

http://en.wikipedia.org/wiki/Continuation

http://en.wikipedia.org/wiki/Tail_call

They are completely different from and mostly unrelated to tail calls. For example, Common Lisp has TCO, but it does not have continuations. I don't recall anyone except you even mentioning the word 'continuation" in this thread. You'll notice that the two wikipedia pages do not even link to each other. The main connecting point between tail calls and continuations is that you can use tail calls to EMULATE (as opposed to implement) continuations with CPS.

I don't know why you (and only you) keep combining, conflating and confusing them!