"SPITZ, HOBART CTR DFAS" wrote: > "... | locate 41.80 substr 10.3 of var Fred | ..." /* Look for > chars in 10-12 of Fred in pos 41-120 of record */
That suggests a more general change to LOCATE to make it a kind of super-PICK, accepting an input range as the string to locate: ... | locate 41.80 10.3 | ... Given that, what you suggest basically means allowing an input range to be a VAR, and allowing an output placement for SPECS to be a VAR. > Thinking about 'TRACKING' gives me a headache, but it could be useful in > some situations, and confusing in others. Could the keyword 'TRACKING' > be used to control it...? Sounds like the most sensible thing to me. We'd also want to be able to specify how many variable pools to go back, and we'd need a keyword for that. LEVEL? DEPTH? POOL? GENERATION? And of course all the other keywords from the VAR stage. Thinking about Rob's idea of retrieving the variable during scanning (or really any other time before committing, just so that nothing in the pipeline would have written to it yet), I wonder if it would be useful, both here and in the VAR stage, to make a distinction between that and retrieving it the first time it's requested. ¬R
