in reply to qr// with /e?

The fact is that /e is only applicable to the right-hand-side of a s/// operator. In other words, you can't use /e to evaluate code on s/this side//e. It only affects s//this side/e.

qr//, builds up the RE that can be used on s/this side// of the s/// operator. Thus, just as /e has no relevance to m//, it has no relevance to qr//, nor to s/this side//.

perlretut discusses this briefly: "A modifier available specifically to search and replace is the s///e evaluation modifier. s///e wraps an eval{...} around the replacement string and the evaluated result is substituted for the matched substring. s///e is useful if you need to do a bit of computation in the process of replacing text."

You're talking, it seems, about allowing the actual RE portion to be eval{...}'ed prior to the execution of the RE. That is going to be a tough sell and my suspician is that it's going to be nearly impossible to implement correctly. After all, if you eval m/$var+1/ prior to using it as a regexp, is it "$var plus one", or is it "$var repeated one or more times, followed by a 1 character"? And should $var be interpolated prior to the eval, or after the eval but prior to the execution of the RE? Things are tricky enough when it comes to getting it right with the quoted version of eval. Imagine trying to deal with the affects of the RE quote-like operator on top of your eval!


Dave

Replies are listed 'Best First'.
Re: Re: qr// with /e?
by tkil (Monk) on Apr 24, 2004 at 23:37 UTC
    The fact is that /e is only applicable to the right-hand-side of a s/// operator.

    Please see my clarification(s) to my original post on this thread. I'm quite aware of (although I was somewhat taken aback by) the current behavior.

    I was looking for others' opinions on this idea. And I've gotten some (mostly indifferent to negative, alas).

    It seems that what I really want is a way to apply qr to an expression without having to stick it into a variable first. Upthread someone suggested an explicit Regex->new( EXPR ) syntax; my response was to just use qr->( EXPR ). (Sigh, that would break if someone used hyphens as the non-alphanumeric delimiters...)

    (This is, in my mind, a similar situation that \Q and \E found themselves in; being able to escape metacharacters is useful even outside of double-quoted interpolation, so quotemeta is available as a standalone. Hm. Maybe quoteregex is where it's at? Although introducing a new keyword is probably not going to happen...)

    You're talking, it seems, about allowing the actual RE portion to be eval{...}'ed prior to the execution of the RE.

    I realize that it could seem that way, but my request for /e is much closer in spirit to /o than to any of the other match modes. I would only want the /e to apply when qr// is compiling the expression: it would tell qr that the text inside the brackets should be evaled to return a string, as opposed to interpreting the text between the brackets as a value to be double-quote interpolated to return a string. (This is why it seems to resonate with s///e, as the modifier is saying exactly the same thing about the replacement text.)

    Anyway. It's absolutely not necessary, I was just curious what other people thought of the idea. Thanks for your feedback!

[reply]
      I'm starting to gain a better understanding of your point. But just remember this: According to the "Gory details of parsing quoted constructs", the following steps take place:

      1. Finding the end. (Compiletime)
      2. Removal of backslashes before delimiters. (Compiletime)
      3. Interpolation. (Compiletime)
      4. Interpolation of Regular Expressions. (Runtime)
      5. Optimization of RE Code (Runtime)

      My question is how would you suggest /e be implemented: Before step 3, or after it? I don't know the answer to this, and I'm not sure what the ramifications would be. Currently the quoted version of eval interpolates variables in step 3, and that's why you sometimes have to escape variable names to delay their evaluation until execution time. It seems that it's destined to be a convoluted road to travel.


      Dave

[reply]

        You know, this response is itself enough to make me agree that qr//e is a bad idea. Thanks for taking the time to beat it into my thick skull. I now think that true eval is overkill.

        (Although, to be fair, the issues you bring up are already solved for the replacement text in s///e, are they not?)

        Having said that, can you think of a syntax that would express my intent of applying qr to a value that is generated some way other than double-quote or regex interpolated? My original examples, for reference: 

          my @days    = qw( Sun Mon Tue Wed Thu Fri Sat );
  my $days_re = do { my $tmp = join '|', @days; qr/$tmp/; }

        [download]

        Using some of the other ideas that have cropped up, I could perhaps just do this: 

          sub compile_regex ( $ ) { qr/$_[0]/; }

  my $days_re = compile_regex join '|', @days;

        [download]

        Although I still like the cuteness factor of doing it this way: 

          my $days_re = qr->( join '|', @days );

        [download]

        Too bad that breaks valid code.

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom