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
Received on Tue Mar 01 2016 - 21:56:41 CET