Being pretentious, and getting away with it.

[japhy]

So there I am, writing my regex book. I document split() rather extensively, and then someone tells me I got it wrong. How disappointing.

So there I am, at TPC, listening to Damian Conway talk about "Data Munging" in his tutorial on Monday. He starts talking about split(), and I correct him. It turns out that I'm wrong (in the same way I was wrong in my book). So I've got two strikes.

One would think, at this point, I'd cash in my chips, correct the text in my book, and sink back into my cave. Nuh-uh.

Some people would fix their book to be consistent with the language. I fixed the language to be consistent with my book! Let me explain:

In Perl 5.005_02, split /(A)|B/, "1A2B3" returned a five-element list of (1, 'A', 2, undef, 3). In 5.005_03, it returned (1, 'A', 2, '', 3); a subtle, but meaningful, difference. There's only one way to get an undef from split(), and that's from the underlying regex match. A capturing paren that does not match has undef as its $DIGIT value.

A tiny bit of incorrectly written code in pp.c:pp_split() caused these undefs to become empty strings. Bah. I corrected it, documented it, and tested it.

So that's my story of being a pretentious bastard, and insisting Perl work the way I think it should (and the way it worked before, and that makes more sense, and that is now tested and documented).

_____________________________________________________
Jeff japhy Pinyan: Perl, regex, and perl hacker.
s++=END;++y(;-P)}y js++=;shajsj<++y(p-q)}?print:??;

[runrig]

How long has it been that regexes have returned anything predictable from non-matching parenthesis within regexes that match?

With a regex like /A(.)?B/, perl used to fill $1 with whatever the last attempt at a match was, and so the result was not undefined, but unpredictable. So on a string like 'AB', you'd end up with 'B' in $1, and although it might be non-intuitive, it was actually conceptually correct, because the string does match /A(B)?B/, and it was up to the programmer to use something more sensible, like </code>/A((.)?)B/</code>, and only depend on the inner parenthesis if the outer ones contain something besides the empty string.

But now I guess perl just does (or will do) the right thing :)

[aquacade]

A quick test of 5.6.1 build 628 using (did I do this correctly?):


for (split /(A)|B/, "1A2B3") {print "'$_' defined\n" if (defined);}

Produces same results as your 5.005_03 example? Your correction would revert to the 5.005_02 behavior with undef's coming through?

Is this a bug in split in the latest release?

I'm somewhat confused by this node as a newbie. (Please don't stone me!)

[japhy]

The bug has existed since 5.005_03. In the next version of Perl, it will be corrected.

_____________________________________________________
Jeff japhy Pinyan: Perl, regex, and perl hacker.
s++=END;++y(;-P)}y js++=;shajsj<++y(p-q)}?print:??;

[BrentDax]

You are a sick man. ++japhy. :^)

=cut
--Brent Dax
There is no sig.

[japhy]

Look for a full report of my dealings with my regex parser in an upcoming node. It'll be called, quite appropriately, "Sick and Twisted".

_____________________________________________________
Jeff japhy Pinyan: Perl, regex, and perl hacker.
s++=END;++y(;-P)}y js++=;shajsj<++y(p-q)}?print:??;

[John M. Dlugosz]

So you're saying it worked right in 5.005_02, was broken in 5.005_03, and is repaired again in 5.7 bleadpearl?