Dan Sugalski <[EMAIL PROTECTED]> wrote:At 11:45 AM +0200 10/29/04, Leopold Toetsch wrote:
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.
Ok. This sounds like the traceback object *is* the continuation ;)
Yep.
What about:
$P0 = interpinfo .INTERPINFO_CURRENT_CONT # implemented already
printerr $P0 # does $P0->vtable->getstring(), which creates # a traceback string, maybe verbosity depending # on debug settings
OTOH having get_string the whole traceback chain isn't really good for overriding it. So maybe it should return just the info for the current call.
I was thinking something a bit more primitive. Since we can treat the call chain as an array, we could do:
$S0 = insert_opname_here [0; 'subname'] # Get the current sub name $S1 = insert_opname_here [1; 'subname'] # Get the caller's sub name $P1 = insert_opname_here [2; 'pad'] # Get grandparent's pad
We could do the same thing with continuation objects -- access them as an array and pull parts out, which'd work fine.
I think having methods is ok for that. It's in no way time critical to warrant opcodes.
The one downside to methods is that we need an object, which means that we've got to instantiate the current continuation. Unless the speed hit there's what you were talking about with not time-critical, in which case I can live with that. I'm not sure I'd want to go with methods here, though -- there's a reasonable chance that the method code might mess up some of the environmental info in the traceback.
>>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.
When and in which run loop do we update the C<current_pc>[1] ? Only, when warnings are enabled or always?
We should always be able to get a sane value out of it. If that means with the JIT that we have to play some interesting games with line number metadata sections or something, well... that's OK. It doesn't have to be cheap, just doable.
> 1) Dumps of call chains and state > 2) Evil parent environment twiddling
> For #2, which includes doing things like upvar and otherunpleasantness, 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.
What for is that needed? Well, if the lexical scope PMC is available by introspection, you can of course add variables to it, with all the consequences that *might* arise from such hacks.
Yep.
There are fairly unusual cases where a subroutine would want to alter the state of its calling sub or method. You might want to conditionally mess around with the caller's warning state or stricture level or something. Should be rare, but I can see doing it. Tcl's got upvar too, so I suppose we really have to do this.
> Dunno if we want to have a PMC that has this Evil Knowledge, or if wewant 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.
Methods ought to be explicit enough.
Nah. I really, *really* want to force people writing compilers to have to special-case the code. Which, I admit, is a bit petty, but dammit if someone's going to be screwing around with the internals like this then I want to force them to be really explicit about it.
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
