On Tue, Mar 01, 2016 at 06:12:32PM +0000, Connor Lane Smith wrote: > We agree for pretty much the same reasoning. (I'm not sure > why you assumed otherwise.)
Misunderstanding on my part I guess. These are just limitations of the regex(3) API but have no particular relevance for *structural* regular expressions. I.e. it is possible to build a structural regexp library on top of this crippled interface it probably just wont be particularly efficient. > > The corresponding section of the vis README[1] also has a few links to > > existing engines / algorithms used etc. > > I'm very familiar with the literature. Good to know, in this case you are probably more up to date than I am. For example a quick search led me to "Efficiently extracting full parse trees using regular expressions with capture groups" which I hadn't seen before. What is in your opinion the current state of the art technique/algorithm? > I think it's also worth looking > at the work of Grathwohl et al. (2013, 2014). For others wanting to take a look, I guess you are referring to the following papers: - Two-pass greedy regular expression parsing - Optimally Streaming Greedy Regular Expression Parsing > Anyway, this is why I > say such a library would need "quite careful planning." I agree. -- Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: 10C93617
