in reply to Finally, a $& compromise!

Neat idea. I don't think it is very practical, tho. The way it is currently designed we'll need to update tons of modules to add "no re::ampersand;" to each file and only then will you be able to use $& in your scripts without the regex in modules being slowed down.

Similarly, if I want to write a module that use $&, I can't do it in a way that protects the scripts that use my module from the performance penalty.

For this to be practical, you need to be able to isolate the penalty of $& to a lexical block. So that I could say:

{ use re::ampersand; $x =~ /.{10}/; $y= $&; }
and the presense of use re::ampersand would make the penalty of "saw ampersand" go away outside of that block.

I agree that the lack of re::ampersand should keep the old behavior of global slow-down. But you need to come up with a better way to accomplish this for this neat idea to be of real practical value.

I guess you could add a new variable, say "expectampersand" and have regex be "slow" in code compiled where "expectampersand" was true or when "sawampersand" was true at run time. And then you would set "sawampersand" whenever you saw one of the three "problem" variables at compile time during a phase when "expectampersand" was false.

So "sawampersand" would mean that you saw one of the variables outside of a block that did use re::ampersand and a new lexically-scoped compiler hint, "expectampersand", would be added. Noncapturing regexes would be slower within lexical scopes that did use re::ampersand and noncapturing regexes everywhere would be slower if you ever used one of the "problem" variables outside of such a lexical scope.

On top of this, you could add your current feature of no re::ampersand so that you could also have some code that does lots of non-capturing regex work that you don't want to be penalized in the face of someone somewhere using a "problem" variables w/o scoping the impact. But I think the other feature is much more important.

Make sense? Is that along the lines of what was already suggested by Hugo and Jarkko?

It is kind of like "fence in" vs. "fence out" states in regard to cattle... (:

        - tye (but my friends call me "Tye")

Replies are listed 'Best First'.
Re: (tye)Re: Finally, a $& compromise!
by japhy (Canon) on Nov 28, 2001 at 21:34 UTC
    You brought up the same point as what was suggested by Hugo and Jarkko, and I'm pleased to present a modified version of the pragma. It comes with one caveat: please do not do no re::ampersand unless you're aware of the consequences. If you do that, then any $& found in the no re::ampersand block will set the PL_sawampersand flag for your program. This doesn't sound like a good idea to me, so I advise against using it. I'm still trying to find some way to make PL_sawampersand work like a stack somehow... so that the no re::ampersand doesn't leak like that.

    Check out New $& Approach, thanks to Hugo, Jarkko, Tye, and others.

    _____________________________________________________
    Jeff[japhy]Pinyan: Perl, regex, and perl hacker.
    s++=END;++y(;-P)}y js++=;shajsj<++y(p-q)}?print:??;