develooper Front page | perl.perl5.porters | Postings from October 2007

Re: [PATCH] New failing test for RT#45667 (m/[#]/x treated inconsistently)

Thread Previous | Thread Next
Dave Mitchell
October 30, 2007 09:10
Re: [PATCH] New failing test for RT#45667 (m/[#]/x treated inconsistently)
Message ID:
On Tue, Oct 30, 2007 at 04:30:46PM +0100, demerphq wrote:
> On 10/30/07, Dave Mitchell <> wrote:
> > On Tue, Oct 30, 2007 at 03:04:28PM +0100, demerphq wrote:
> > > Probably is. But im not entirely comfortable with the original patch.
> > > Its not clear to me that we can change this behaviour anymore. At
> > > least not in the regex engine. Its actually probably easier to change
> > > this in the perl parser, which we long term intend to change anyway in
> > > order to resolve the whole qr// as closure stuff as well as variable
> > > bindings amongst other issues.
> > >
> > > Probably a good idea if Dave Mitchell speaks up on this one as to my
> > > knowledge he has the most developed idea of the future of this.
> >
> > The bug's definitely in the perl parser, and I still intend to fix it post
> > 5.10.0. The fix is kinda orthogonal to the qr// and closure stuff.
> Ok. I thought they were related.

Well, they're slightly related, but the two fixes can be developed
independently of each other. They both involve making the tokeniser be a
bit more clever when processing literal strings. There's a function that
scans through characters in a literal string until it finds something
"interesting". For example, in the double-quoted string "abc$d", it stops
at the $ and returns "abc" as a token.  One fix involves stopping that
function thinking that # is interesting when within [], the other involves
making it think that '(?{' is interesting.

> > Actually, there's a bit of uncertainty as to whether I cans still do that
> > qr// stuff, now that there's an API been added to the regex parser: I
> > don't think it can can handle want I would like to pass to it (a mixture
> > of const strings and snippets of opcode trees), of if I could pass it,
> > whether other plugged-in engines (sucha as PCRE) wouldn't choke on it.
> > Anyway, I haven't looked closely at it yet.
> I dont think you should worry about that. I think fixing the general
> behaviour takes precedence over supporting experimental regex engine
> plug ins. I believe that the API has been documented to be a work in
> progress anyway, and if it hasnt we should make sure to do so before
> 5.10 is released. Of course if what you design has an api that makes
> it easy for the engine plug ins to adapt it would be a good thing. :-)

Okay :-)

The warp engines start playing up a bit, but seem to sort themselves out
after a while without any intervention from boy genius Wesley Crusher.
    -- Things That Never Happen in "Star Trek" #17

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About