On Mon, 2 Sep 2002, Dan Sugalski wrote: > At 3:59 PM +0000 9/2/02, "Sean O'Rourke" (via RT) wrote: > >rx_stackdepth Ix -- Store the size of the regex stack in Ix > > Make that intstackdepth, since it's a general-purpose stack.
If so, we'll probably also want to change rx_clearstack and rx_initstack. I thought the "rx_" was the naming convention for things that dealt with the interpreter intstack. > >rx_stackchop Ix -- shorten the regex stack to have Ix entries > > Yeek--that's from the wrong end. We need to chop entries off the top, > as we have no idea how many entries were already there. Either way. I thought it was more natural to be able to "save" and "restore" absolute stack depths, so you don't have to track how much stuff gets pushed onto the stack between when you record the depth and when you pop back to it. I think it ends up being two more ops if you say "chop X entries" -- "getdepth; subtract; chop" vs. "setdepth". > I think I'm really, *really* close to tossing the last pretense of > being a stack-based system and move all the way to routine-based > frames instead, which'd definitely make some things easier. I don't think frames help us here. This is basically a poor man's exceptions. It's useful for regexes, where you are only accumulating state on the intstack, so using full exceptions or (heaven forbid) continuations is overkill. I don't know if it's a useful approach outside of a limited regex-backtracking context. > Anyway, it should be intstackchop, and chop X entries off the top of > the stack. Or, if you'd rather, intstackpop ix, and add in "pop X" > versions for the other stacks too. I think these could be useful as well. /s
