On 12/26/05, Patrick R. Michaud <[EMAIL PROTECTED]> wrote: > > I argue that by the structure of that rule, you should be able to tell > > which xs go with which y. > > ... > > Is there a counterargument that I'm not seeing? > > I'd say that if you want a structured rule, it should be written > that way, as in > > ( (x)* y )* > > or > > ( (x)* (y) )*
I wouldn't really call that a counterargument. What I'm after is not "how can I see the correspondence between the inner matches" so much as "how is 'dumb flattening'" useful? It's quite possible that neither of the semantics in my original message are correct. "Deep nesting" seemed much more natural from the implementation side of things, which is why I brought it up. I suppose you could consider dumb flattening to be useful with the following pattern matching two-column text: / [ $<col1>:=(<-[|]>) \| $<col2>:=(<-[|]>) \n ]* / Where @<col1> and @<col2> would then hold the lines in each of the columns. But that is the only case I can think of, and it doesn't generalize to an arbitrary number of columns (that is, not hardcoded into the regex), which makes me think that it's not an important case. On the other hand, I can't see many cases where deep nesting buys you much where using capturing parens doesn't. It basically spits out the transpose of the same structure. The thing that makes it feel more correct to me is that: (1) it has the same amount of asymptotic memory overhead, and (2) it keeps more information. It may be convenient to work with flattened arrays, but needlessly throwing away information is not usually a wise move. We can provide a "deep flatten" function that makes the flat structure only one function call away; you can't say the same thing going the other direction. But still, the thing that's going to make the decision clear is examples. Luke  By which I do *not* mean "easier". In fact, it was a good deal harder. It's hard to say exactly what I mean...  If it did generalize, then I would consider it much more important.