Re^4: Progressive matching w/substitutions

[argv]

Why doesn't this work?

Read up on the return value of s/// in scalar context.

That doesn't apply. both m// and s/// return values that can be interpreted by a while() construct to evaluate to a boolean. The point isn't what the s/// expression returns, it's whether matching (then substitution) ia done "progressively" as the documentation says it would for m// in the context of a while() loop. The fact that the documentation doesn't say anything about s/// (at least, not in the ORA perl book) leads me to consider it to be either an oversight in implementation, or an outright bug. :-/

calls to other functions have to be made

What do you think sprintf is? The body of the loop is the replace expression. Put the die in there.

No, that would be involved and overly obfuscated. Granted, it can be done, and there's no question that perl is robust enough that you could implement any solution using its existing implementation. but just because there's "another way to do it" is not a good reason to always defend an aspect to the current design that may be potentially... well, "undefined".

I'm not trying to be argumentative; I'm only trying to focus on this one aspect of s/// and how "progressive matching" has been defined/implemented. I appreciate the explanations for how ELSE to accomplish the task, but that's not what I'm hoping to discuss.

[tye]

Modifying a string's value resets pos.

[argv]

Modifying a string's value resets pos.

That's not in the doc that I've seen -- "perldoc -f pos" doesn't show it, and it doesn't seem to be anywhere in the ORA Programming Perl book (3rd Ed.). So, how do you know this? Experimentation? Looking at the source? Whatever the answer, I still think there should be a definitive spec as to what progressive matching covers.

I would think that s/// is in the same family as m// simply because matching has to be done "exactly the same way" -- it could even be considered a convenience function. Therefore, I would say that 'progressive matching'for s/// should follow the same rules that m// does in while() loops.

And that brings us back to pos and my question about how you know that pos resets to 0 if the string is modified. If it's *specified* to do that, that's one thing--but if it's just an artifact of implementation (ie., it's not formally documented as a spec), then I'd say it could be changed, and s/// could then become compliant (and consistent) with existing specs. dan

[tye]

Common sense. Confirmed by observation.

Actually, I have a module that supports just this type of thing and more that I hope to finish and release to CPAN this year, anyway.

pos doesn't apply to s/// just like it doesn't apply to pack/unpack or anything else. pos only talks about m//g and that is the only thing that it applies to. It doesn't talk about the things that it doesn't apply to and it doesn't apply to s/// nor split. Similar for \G.

The way you run code between steps of s/// is to use s//.../ge. You can't do that with m//g and, similarly, you can't do while( s///g ) { .... }.