in reply to Re: qr// with /e?
in thread qr// with /e?

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!

Replies are listed 'Best First'.
Re: Re: Re: qr// with /e?
by davido (Cardinal) on Apr 25, 2004 at 00:01 UTC
    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