We now have since quite a time the current subroutine and the current continuation in the interpreter context structure. With that at hand, we should now be able to generate function tracebacks in error case and we need the call chain too, to optimize register frame recycling.
Whenever a continuation is created, we have to walk up the call chain and mark all return continuations as non-recyclable.
Should the traceback object be avaiable as a PMC?
Nah, I don't think so. There's nothing in the traceback that wouldn't be in the current continuation, so I don't think it's worth bothering. If someone wants to preserve the traceback they can just hold onto a continuation. (Unless we want the traceback to be more static, in which case holding onto it would be more like freezing the current continuation)
Basically we want to be able to walk a continuation chain and get access to everything. For performance reasons (because of people who fall in category 2 (which I'll get to)) we want to do it either with an arbitrary continuation object or with the current continuation without actually instantiating the current continuation.
What information should be included in the traceback (object)?
Everything. It seems to me that there are two big things people will do with traceback info.
1) Dumps of call chains and state 2) Evil parent environment twiddling
For #1 we'll want to be able to walk up the chain and yank out sub/method names, the object being method-called, the lexical pads in effect, the namespace as it stands, and suchlike stuff. (I'm told that Python has a very nice verbose dump such that when it dumps you get not only the call tree but the variables and their values, which strikes me as good in two ways -- it makes debugging easier and it makes those sorts of errors harder to ignore because the output's so damn big)
For #2, which includes doing things like upvar and other unpleasantness, we'll be taking advantage of the fact that while we can't necessarily touch the actual interpreter/continuation chain, anything we fetch out of it (like, say, the lexical scope) is touchable, so injecting variables into your caller's scope isn't a big deal.
Dunno if we want to have a PMC that has this Evil Knowledge, or if we want to have ops. Part of me leans towards an op or two -- if for no other reason then to force it to be very explicit in any language that does it, which will make people think and make it really tough to do accidentally.
--
Dan
--------------------------------------it's like this------------------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk