Possibly Pythonic Tail Call Optimization (TCO/TRE)

[Chris Angelico]

On Tue, Jul 14, 2015 at 3:15 PM, Paul Rubin <no.email at nospam.invalid> wrote:
> Chris Angelico <rosuav at gmail.com> writes:
>> I'm not sure why the transition to another state has to be recursive.
>
> It's not recursive: it's more like a goto with arguments, and a tail
> call expresses it nicely.

Hmm, maybe, but I'm not sure that the transition to another state is a
goto with arguments. What triggers the transition? Is it a linear
protocol? Is it a nested protocol that completes some operation and
returns to a base state? How are these transitions recognized, and why
is that needing a "goto with arguments" to express it?

>> Maybe this is something where previous experience makes you more
>> comfortable with a particular style, which will mean that functional
>> idioms will never feel more comfortable to me than iterative ones do,
>> and vice versa for you. If that's the case, then I'll stick with
>> Python and Pike, and you can happily use Lisp and Haskell, and neither
>> of us need be a problem to the other.
>
> Do you also use explicit loops instead of list comprehensions?  They are
> another nice functional idiom adapted into Python.

I use list comprehensions, but that's not the same thing as using
functional programming. What that means is that there's nothing that
we can't learn from. I'm glad functional languages exist, where people
try to make everything have no side effects and be deterministic; it's
a good discipline, and worth being aware of even when your language
doesn't enforce it. But just because functional languages like to say
"take this array and multiply every element by 4" and I like using
that same feature, that doesn't mean that I want to do everything in a
functional style.

Here's an alternative way of expressing that thought.

Do you write code such that each line does one simple thing? That's a
nice assembly language practice that's been adapted into Python.

Assembly languages tend to enforce a "one line, one operation" rule.
Python programmers often adhere to that (you don't generally see a
bunch of stuff separated by semicolons, and even "for line in lines:
print(line)" is frowned upon - add a newline!), but that doesn't mean
we want all the other trappings of assembly languages.

ChrisA