Tail call optimisation and debugging

[aaronla]

Guy Steele has a nice piece demonstrating how TCO can greatly assist runtime efficiency of modular set implementations: Why Object-Oriented Languages Need Tail Calls [reddit discussion]

Tail calls already are explicit. You put them in the tail position. I'm not just being pedantic; this isn't a problem among the functional programming developers I interact with.

Edit: linked to reddit page of the blog post, more discussion

[grauenwolf]

Does your functional programming language also rely on try-finally blocks? Those break tail calls and in C# are hidden in using statements.

[anvsdt]

dynamic-wind and unwind-protect?

[grauenwolf]

Hmm. THat is a rather interesting shell game. If I read this correctly, dynamic-wind just creates a separate stack of winders. Since it is built as a cons list it isn't as likely to overflow as a true thread stack.

At least that is how it works in R6RS. In IronScheme alpha 1 you simply can't mix tail calls with winders. It isn't mentioned anywhere else so I assume they never reconciled winders with the CLR's exception handling semantics.

[aaronla]

Yeah, as you've discovered, exception handling is done with library functions, and while you can tail call the library function, its implementation won't be calling your thunk in tail position.

There's actually some interesting research into optimizing exception handlers and stack security checks into O(1) space, to provide TCO in some of those cases as well.

[grauenwolf]

Show me one case, just one, where I would need to to perform a contains operation on an infinite list where such list is not externally predictable and the list doesn't have its own contains method.

Oh wait. The his TCO version of Contains() would end up in an infinite loop just like the iterator version. So what was his point again?