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= $&;
}

[download]
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")

In reply to (tye)Re: Finally, a $& compromise! by tye
in thread Finally, a $& compromise! by japhy

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.