Re: boost::regex: regex meta data or AST for regex?
Seth <[email protected]> Fri, 5 Feb 2021 01:23:02 +0100
| Newsgroups | gmane.comp.parsers.spirit.general |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--===============5249041952023782418==
Content-Type: multipart/alternative;
boundary="------------053730B0CDFC17585F6540D0"
Content-Language: en-GB
This is a multi-part message in MIME format.
--------------053730B0CDFC17585F6540D0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Op 24-01-2021 om 15:04 schreef Frank Bergemann:
> On 21.01.21 02:09, Seth wrote:
>> Op 19-01-2021 om 19:07 schreef Frank Bergemann:
>>> Hi Seth,
>>>
>>> isn't Xpressive about static regexes at compile time, plus a wrapping
>>> for both: dynamic _and_ static regexes?
>>> How can that help to create an AST for a dynamic regular expression
>>> (string)?
>>
>> It actually cannot (see https://stackoverflow.com/a/7659255/85371) but
>> it might do what you were hoping to achieve - I don't claim I understood
>> much of the goal.
>>
>> Also, that's why I linked to the other answer there because it DOES
>> create an AST from dynamic regulare expressions (string).
>> https://stackoverflow.com/a/21419351/85371.
>>
>> Right off the bat I sense confusion in the name ("RegexSplitter" -
>> regexes aren't split, they're _parsed_) and the way you attack the
>> grammar (which appears to be more about scanning than parsing?). Instead
>> of me poring over your code and making sense of your code you can look
>> at mine for inspiration
>>
>> Sorry I can't be of more active help.
>>
>> Good luck,
>>
>> Seth
>>
>
> Hi Seth,
>
> please see my original post:
> >> in concrete:
> >> Is it possible to not only get the #no of groups (sub-expressions)
> >> via basic_regex::mark_count(), but also their position (begin() /
> >> end() iterators) in the given regex string (c'tor argument)?
>
> Actually, it's a even simpler: I want to split a regular expression
> string into TOP LEVEL groups and non-group areas (substrings).
> E.g. "here is( some| any| a) string( with optional( data| text)( at
> the end)?)?"
> Should be split into #4 substrings:
> "here is"
> "(some | any| a)"
> " string"
> (with optional( data| text)( at the end)?)?"
>
> I.e. i do NOT need to break up groups again this way, recursively.
As I mentioned somewhere before, you do. You just don't want to
represent that in the AST always.
You have realized this as evidenced from the code linked in your latest
SO question (https://stackoverflow.com/q/66050263/85371).
You're running into many problems due to using polymorphic attributes,
semantic actions, raw fusion handling and complicated tricks to
reconstruct original input from synthesized attributes.
May I suggest **not** doing all these, and using `qi::raw[]` to get at
the matched input directly. Now you can do away with all the (manual)
dynamic allocation, complicated string types/manipulation, all the
semantic actions, the duplication of the rules, and a third of the
remaining rules and it will just work.
I did a review of the code, and reduced it all the way down to ~40 lines
of code. See a Live Demo: https://wandbox.org/permlink/DmguiV9MEIFo32nP
The individual commits are here
https://github.com/sehe/RegexSplitter/tree/sehe. You might also want to
review the earlier commits (before reductions). E.g. the simplification
of all the PARSE_ONLY conditionals to a single-line change.
CAVEAT:
* IMO the grammar is flawed (beyond the TODO). E.g. quantifiers should
be allowed on any atom. I see a only single, hardcoded quantifier
(trailing-?).
It still seems you are confusing jargon w.r.t the regular expression
syntax (calling things grouped/nongrouped here, breakable/unbreakable
elsewhere. If I had to guess this is where the much of the complication
arises from.
In one's quest to simplify things it is important nevert to make it
"simpler than than possible", or you'll end up making it much more
complicated instead.
--------------053730B0CDFC17585F6540D0
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">Op 24-01-2021 om 15:04 schreef Frank
Bergemann:<br>
</div>
<blockquote type="cite" cite="mid:[email protected]">On
21.01.21 02:09, Seth wrote:
<br>
<blockquote type="cite">Op 19-01-2021 om 19:07 schreef Frank
Bergemann:
<br>
<blockquote type="cite">Hi Seth,
<br>
<br>
isn't Xpressive about static regexes at compile time, plus a
wrapping
<br>
for both: dynamic _and_ static regexes?
<br>
How can that help to create an AST for a dynamic regular
expression
<br>
(string)?
<br>
</blockquote>
<br>
It actually cannot (see
<a class="moz-txt-link-freetext" href="https://stackoverflow.com/a/7659255/85371">https://stackoverflow.com/a/7659255/85371</a>) but
<br>
it might do what you were hoping to achieve - I don't claim I
understood
<br>
much of the goal.
<br>
<br>
Also, that's why I linked to the other answer there because it
DOES
<br>
create an AST from dynamic regulare expressions (string).
<br>
<a class="moz-txt-link-freetext" href="https://stackoverflow.com/a/21419351/85371">https://stackoverflow.com/a/21419351/85371</a>.
<br>
<br>
Right off the bat I sense confusion in the name ("RegexSplitter"
-
<br>
regexes aren't split, they're _parsed_) and the way you attack
the
<br>
grammar (which appears to be more about scanning than parsing?).
Instead
<br>
of me poring over your code and making sense of your code you
can look
<br>
at mine for inspiration
<br>
<br>
Sorry I can't be of more active help.
<br>
<br>
Good luck,
<br>
<br>
Seth
<br>
<br>
</blockquote>
<br>
Hi Seth,
<br>
<br>
please see my original post:
<br>
>> in concrete:
<br>
>> Is it possible to not only get the #no of groups
(sub-expressions)
<br>
>> via basic_regex::mark_count(), but also their position
(begin() /
<br>
>> end() iterators) in the given regex string (c'tor
argument)?
<br>
<br>
Actually, it's a even simpler: I want to split a regular
expression string into TOP LEVEL groups and non-group areas
(substrings).
<br>
E.g. "here is( some| any| a) string( with optional( data| text)(
at the end)?)?"
<br>
Should be split into #4 substrings:
<br>
"here is"
<br>
"(some | any| a)"
<br>
" string"
<br>
(with optional( data| text)( at the end)?)?"
<br>
<br>
I.e. i do NOT need to break up groups again this way, recursively.
<br>
</blockquote>
<p>As I mentioned somewhere before, you do. You just don't want to
represent that in the AST always.</p>
<p>You have realized this as evidenced from the code linked in your
latest SO question (<a class="moz-txt-link-freetext" href="https://stackoverflow.com/q/66050263/85371">https://stackoverflow.com/q/66050263/85371</a>).</p>
<p>You're running into many problems due to using polymorphic
attributes, semantic actions, raw fusion handling and complicated
tricks to reconstruct original input from synthesized attributes.</p>
<p>May I suggest **not** doing all these, and using `qi::raw[]` to
get at the matched input directly. Now you can do away with all
the (manual) dynamic allocation, complicated string
types/manipulation, all the semantic actions, the duplication of
the rules, and a third of the remaining rules and it will just
work.</p>
<p>I did a review of the code, and reduced it all the way down to
~40 lines of code. See a Live Demo:
<a class="moz-txt-link-freetext" href="https://wandbox.org/permlink/DmguiV9MEIFo32nP">https://wandbox.org/permlink/DmguiV9MEIFo32nP</a></p>
<p>The individual commits are here
<a class="moz-txt-link-freetext" href="https://github.com/sehe/RegexSplitter/tree/sehe">https://github.com/sehe/RegexSplitter/tree/sehe</a>. You might also
want to review the earlier commits (before reductions). E.g. the
simplification of all the PARSE_ONLY conditionals to a single-line
change.</p>
<p>CAVEAT:</p>
<ul>
<li>IMO the grammar is flawed (beyond the TODO). E.g. quantifiers
should be allowed on any atom. I see a only single, hardcoded
quantifier (trailing-?).</li>
</ul>
<p>It still seems you are confusing jargon w.r.t the regular
expression syntax (calling things grouped/nongrouped here,
breakable/unbreakable elsewhere. If I had to guess this is where
the much of the complication arises from.</p>
<p>In one's quest to simplify things it is important nevert to make
it "simpler than than possible", or you'll end up making it much
more complicated instead.</p>
<p><br>
</p>
<p><br>
</p>
<p><br>
</p>
</body>
</html>
--------------053730B0CDFC17585F6540D0--
--===============5249041952023782418==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
--===============5249041952023782418==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Spirit-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/spirit-general
--===============5249041952023782418==--