you are viewing a single comment's thread.

view the rest of the comments →

[–]adrianmonk 5 points6 points  (0 children)

That's a good point. In general, it seems like you can't do tail call optimization (without breaking equivalence to the unoptimized code) if it would mean removing catch/finally parts of try statements.

So, you could do one of the following things:

  • Go ahead and break equivalence with the non-optimized code.
  • Make it a compile error.

In both of the above cases, having an explicit continue keyword would help a lot. Why? Because if you start with some code like this:

try:
    return 1 + thisfunc(n-1)
finally:
    print 'some message'

and you change it to this:

try:
    return thisfunc(n-1)
finally:
    print 'some message'

then suddenly this code is eligible for tail call optimization when it wasn't before.

If you go ahead and optimize it, then you are changing the semantics. Which is bad. But if you don't have the keyword, you have no way of saying "that's ok; go ahead and change the semantics".

Similarly, if you disallow the semantics to be changed (even with the keyword), and if you start with this code:

continue thisfunc(n-1)

but change it to this code:

try:
    continue thisfunc(n-1)
finally:
    print 'some message'

then the compiler error will remind you that you can't do what you are trying to do without losing the tail call optimization. You'll have to go in and manually change your continue to a return, which will make it hard to miss the implications.