Dave Mitchell <[EMAIL PROTECTED]> wrote:
:I'm currently working on a patch to handle (?{...}) code snippets better.
Cool.
:This is as fine and dandy as far as it goes. The problem I have is that
:some literals are used as patterns, but are not recognised as patterns by
:the tokenizer, specifically
:
: $foo =~ 'pattern';
:and
: split 'pattern', $foo;
:
:(Note the lack of //'s or the 'm' quote oerator).
Hmm, yacc must know that these are patterns, is it not possible to
introduce the relevant expectation to toke.c? [Later: ah ok.]
:My preferred way of handling this is to treat this as a run-time (?{})
:pattern
"this" what? All literal strings used as patterns? Or only those with
(?{...}) in them? I'm assuming the latter, but even then it seems
a regrettable change: that really isn't a variable.
:A third possiblity, letting the tokenizer know, based on context, that a
:following string is a pattern, would get messy, eg
:
: $foo =~ ("abc\b" . bar("baz"))
:
:where baz mustn't be treated as a regex string. For that matter, "abc\b"
:must still have the \b converted to a bell char rather than being left
:untouched for the regex engine. Very messy.
Hmm, I see the point. Would it be possible as a starting point to
introduce a compile-time warning if a literal string supplied as a
pattern includes any meta-characters? In general I start to worry about
maintainability of perl code as soon as I see something like:
next if $name =~ 'foo\s+bar';
That'd give us a chance to see how widespread the use is of constant
strings as full regexps, which might give us a better basis to estimate
the chance of breakage with your proposed change.
Hugo
