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[1] 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.[2]
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
[1] By which I do *not* mean "easier". In fact, it was a good deal
harder. It's hard to say exactly what I mean...
[2] If it did generalize, then I would consider it much more important.
