Store captures and non-captures in source-string order

2008-10-12 Thread Moritz Lenz
When we write regexes, we generally capture stuff in a way that makes the following semantic analysis easier. For example we could have a regex m/ + ? */ if we're only interested in the match trees of what and matches, not their respective order. But if you want to re-used the match tree for som

Re: Store captures and non-captures in source-string order

2008-10-12 Thread Patrick R. Michaud
On Sun, Oct 12, 2008 at 11:44:05AM +0200, Moritz Lenz wrote: > When we write regexes, we generally capture stuff in a way that makes > the following semantic analysis easier. For example we could have a > regex m/ + ? */ if we're only interested in the match > trees of what and matches, not their

Re: Store captures and non-captures in source-string order

2008-10-12 Thread Moritz Lenz
Patrick R. Michaud wrote: > On Sun, Oct 12, 2008 at 11:44:05AM +0200, Moritz Lenz wrote: >> When we write regexes, we generally capture stuff in a way that makes >> the following semantic analysis easier. For example we could have a >> regex m/ + ? */ if we're only interested in the match >> trees

Re: Store captures and non-captures in source-string order

2008-10-13 Thread Larry Wall
On Sun, Oct 12, 2008 at 05:34:49PM +0200, Moritz Lenz wrote: : Patrick R. Michaud wrote: : > On Sun, Oct 12, 2008 at 11:44:05AM +0200, Moritz Lenz wrote: : >> When we write regexes, we generally capture stuff in a way that makes : >> the following semantic analysis easier. For example we could have

Re: Store captures and non-captures in source-string order

2008-10-13 Thread Larry Wall
Or maybe we're not thinking big enough here. Maybe we're looking at a generalized tree query language that, as limiting cases, defines the .splits and .allsplits as (re)linearized query results, where .splits linearizes the top level nodes, and .allsplits linearizes the leaves, but may intermediat

Re: Store captures and non-captures in source-string order

2008-10-13 Thread Aristotle Pagaltzis
* Larry Wall <[EMAIL PROTECTED]> [2008-10-13 19:00]: > Maybe we're looking at a generalized tree query language That’s an intriguing observation. Another case for having some XPath-ish facility in the language? Regards, -- Aristotle Pagaltzis //