Re: Tailcalls. Was Re: Manual timeslicing the VM.

[Glenn Maynard <glenn@...>]

On Fri, Aug 05, 2005 at 01:06:40PM -0500, Rici Lake wrote:
> 
> On 5-Aug-05, at 12:53 PM, Glenn Maynard wrote:
> 
> >Here, I was referring to self-recursion: it may make sense, when 
> >debugging,
> >to want to know which function kicked off a tight recursion, but in the
> >state machine case it feels wrong and unintuitive for a debugging 
> >function
> >being asked "who called this function" to return the function that 
> >started
> >the state machine originally.
> 
> Does it? Would you want the debugging function to show you the 327,432 
> previous states before you saw the function that originally created the 
> maze? Would you want the state machine to fail because of stack 
> overflow?

Personally, I don't care about that in C; I'd consider it very poor,
dangerous practice to write C code that *depends* on tail call optimizations
to work at all.  C programmers have to trust the compiler to optimize, in
order to write sane code, but depending on a particular optimization to
function at all seems like a very bad idea.  Code that did that would blow
up in a debugging (unoptimized) build.  (It's acceptable in Lua, since tail
calls are explicitly defined as part of the language.)

In Lua, I don't expect to see the states--but I do want to be able to see
that stack frames are missing.

In C, in the general (non-recursive) case, it's a legitimate speed and stack
optimization, but from a "noise in the backtrace" perspective, I find that
it's "noise" that they're missing, since it's one more major optimizer-bomb
I have to watch out for in production bug reports.  I can't think of any
reason to *want* those tail calls to be missing from stack traces.

> gcc can be instructed to not insert tailcalls; under some circumstances 
> this is useful, although as the maze example illustrates it can lead to 
> other bugs. Still, for those occasions, and for those who share your 
> intuitions about state machines, it might be reasonable to have some 
> mechanism in Lua for doing the same thing; the nontailcallable closure 
> flag I suggested has the advantage of allowing some selectivity. 
> (Suppose you use a library which unbeknownst to you is implemented with 
> a tailcalled state machine; globally turning tail calls off might then 
> make it impossible to debug your code because the library consistently 
> crashes.)

Er, debugging builds (-O0 -g) in gcc don't do tail call optimizations.  Those
are turned on at -O2.  A library that doesn't work below -O2 is a library
I'd keep my distance from.  :)

-- 
Glenn Maynard