From: "trans.  (T. Onoma)" <transami@...>
Date: 2004-11-12T11:55:53+09:00
Subject: Re: #scan with or'd (`|`) subexpressions.

On Thursday 11 November 2004 11:57 am, Peter wrote:
| > I see. Perhaps there is good reason for this. But I just don't see it. IN
| > practice it causes me to have to strip out a whole lot of nils from the
| > results. Honestly, I can't see how it makes any sense. The regexp will
| > match on the first "or" that succeeds, right? So all the others are by
| > necessity nil. But perhaps I'm overlooking some possibility.
|
| If those nils are stripped, you loose information about which "or"
| succeeded. In some cases that is not important in that it does not matter
| where the captures come from as long as they are interchangeable, but that
| is certainly not always so. Also it makes interpretation of the captures
| very difficult when the different "ors" have a different number of
| captures:
|
|    /(?:(1)(a)|(-))(?:(2)|(b)(+))/
|
| With nils stripped, this can return
| ['1','a','2'],['1','a','b','+'],['-','2'] or ['-','b','+']. If each
| capture needs a different treatment, there's no way to relate the correct
| treatment to the index in the array of captures.

Hi --

Well, I'm not sure how it helps. What I ended up doing was making sure all my 
expressions did have the _same number_ of sub-expressions (in this case 7). 
So then I could count the preceding nils and divide by 7 to find out which 
match. But that's a hack IMHO.

Matz, yourself, and others past have all mentioned being able to figure out 
which match, but how?

Thanks,
T.