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

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

Replies are listed 'Best First'.
Re: Re: Re: Re: qr// with /e?
by tkil (Monk) on Apr 25, 2004 at 00:37 UTC

    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/; }

    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;

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

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

    Too bad that breaks valid code.