186 lines
14 KiB
HTML
186 lines
14 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
<html>
|
|
<head>
|
|
<title>Confix Parsers</title>
|
|
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
|
|
<link rel="stylesheet" href="theme/style.css" type="text/css">
|
|
</head>
|
|
|
|
<body>
|
|
<table width="100%" border="0" background="theme/bkd2.gif" cellspacing="2">
|
|
<tr>
|
|
<td width="10"> <font size="6" face="Verdana, Arial, Helvetica, sans-serif"><b> </b></font></td>
|
|
<td width="85%"> <font size="6" face="Verdana, Arial, Helvetica, sans-serif"><b>Confix Parsers</b></font></td>
|
|
<td width="112"><a href="http://spirit.sf.net"><img src="theme/spirit.gif" width="112" height="48" align="right" border="0"></a></td>
|
|
</tr>
|
|
</table>
|
|
<br>
|
|
<table border="0">
|
|
<tr>
|
|
<td width="10"></td>
|
|
<td width="30"><a href="../index.html"><img src="theme/u_arr.gif" border="0"></a></td>
|
|
<td width="30"><a href="character_sets.html"><img src="theme/l_arr.gif" border="0"></a></td>
|
|
<td width="30"><a href="list_parsers.html"><img src="theme/r_arr.gif" border="0"></a></td>
|
|
</tr>
|
|
</table>
|
|
<p><a name="confix_parser"></a><b>Confix Parsers</b></p>
|
|
<p>Confix Parsers recognize a sequence out of three independent elements: an
|
|
opening, an expression and a closing. A simple example is a C comment:
|
|
</p>
|
|
<pre><code class="comment"> /* This is a C comment */</code></pre>
|
|
<p>which could be parsed through the following rule definition:<code><font color="#000000">
|
|
</font></code> </p>
|
|
<pre><span class=identifier> </span><span class=identifier>rule</span><span class=special><> </span><span class=identifier>c_comment_rule
|
|
</span><span class=special>= </span><span class=identifier>confix_p</span><span class=special>(</span><span class=literal>"/*"</span><span class=special>, </span><span class=special>*</span><span class=identifier>anychar_p</span><span class=special>, </span><span class=literal>"*/"</span><span class=special>)
|
|
</span><span class=special>;</span></pre>
|
|
<p>The <tt>confix_p</tt> parser generator
|
|
should be used for generating the required Confix Parser. The
|
|
three parameters to <tt>confix_p</tt> can be single
|
|
characters (as above), strings or, if more complex parsing logic is required,
|
|
auxiliary parsers, each of which is automatically converted to the corresponding
|
|
parser type needed for successful parsing.</p>
|
|
<p>The generated parser is equivalent to the following rule: </p>
|
|
<pre><code> <span class=identifier>open </span><span class=special>>> (</span><span class=identifier>expr </span><span class=special>- </span><span class=identifier>close</span><span class=special>) >> </span><span class=identifier>close</span></code></pre>
|
|
<p>If the expr parser is an <tt>action_parser_category</tt> type parser (a parser
|
|
with an attached semantic action) we have to do something special. This happens,
|
|
if the user wrote something like:</p>
|
|
<pre><code><span class=identifier> confix_p</span><span class=special>(</span><span class=identifier>open</span><span class=special>, </span><span class=identifier>expr</span><span class=special>[</span><span class=identifier>func</span><span class=special>], </span><span class=identifier>close</span><span class=special>)</span></code></pre>
|
|
<p>where <code>expr</code> is the parser matching the expr of the confix sequence
|
|
and <code>func</code> is a functor to be called after matching the <code>expr</code>.
|
|
If we would do nothing, the resulting code would parse the sequence as follows:</p>
|
|
<pre><code> <span class=identifier>open </span><span class=special>>> (</span><span class=identifier>expr</span><span class=special>[</span><span class=identifier>func</span><span class=special>] - </span><span class=identifier>close</span><span class=special>) >> </span><span class=identifier>close</span></code></pre>
|
|
<p>which in most cases is not what the user expects. (If this <u>is</u> what you've
|
|
expected, then please use the <tt>confix_p</tt> generator
|
|
function <tt>direct()</tt>, which will inhibit the parser refactoring). To make
|
|
the confix parser behave as expected:</p>
|
|
<pre><code><span class=identifier> open </span><span class=special>>> (</span><span class=identifier>expr </span><span class=special>- </span><span class=identifier>close</span><span class=special>)[</span><span class=identifier>func</span><span class=special>] >> </span><span class=identifier>close</span></code></pre>
|
|
<p>the actor attached to the <code>expr</code> parser has to be re-attached to
|
|
the <code>(expr - close)</code> parser construct, which will make the resulting
|
|
confix parser 'do the right thing'. This refactoring is done by the help of
|
|
the <a href="refactoring.html">Refactoring Parsers</a>. Additionally special
|
|
care must be taken, if the expr parser is a <tt>unary_parser_category</tt> type
|
|
parser as </p>
|
|
<pre><code><span class=identifier> confix_p</span><span class=special>(</span><span class=identifier>open</span><span class=special>, *</span><span class=identifier>anychar_p</span><span class=special>, </span><span class=identifier>close</span><span class=special>)</span></code></pre>
|
|
<p>which without any refactoring would result in </p>
|
|
<pre><code> <span class=identifier>open</span> <span class=special>>> (*</span><span class=identifier>anychar_p </span><span class=special>- </span><span class=identifier>close</span><span class=special>) >> </span><span class=identifier>close</span></code></pre>
|
|
<p>and will not give the expected result (*anychar_p will eat up all the input up
|
|
to the end of the input stream). So we have to refactor this into:
|
|
<pre><code><span class=identifier> open </span><span class=special>>> *(</span><span class=identifier>anychar_p </span><span class=special>- </span><span class=identifier>close</span><span class=special>) >> </span><span class=identifier>close</span></code></pre>
|
|
<p>what will give the correct result. </p>
|
|
<p>The case, where the expr parser is a combination of the two mentioned problems
|
|
(i.e. the expr parser is a unary parser with an attached action), is handled
|
|
accordingly too, so: </p>
|
|
<pre><code><span class=identifier> confix_p</span><span class=special>(</span><span class=identifier>open</span><span class=special>, (*</span><span class=identifier>anychar_p</span><span class=special>)[</span><span class=identifier>func</span><span class=special>], </span>close<span class=special>)</span></code></pre>
|
|
<p>will be parsed as expected: </p>
|
|
<pre><code> <span class=identifier>open</span> <span class=special>>> (*(</span><span class=identifier>anychar_p </span><span class=special>- </span><span class=identifier>end</span><span class=special>))[</span><span class=identifier>func</span><span class=special>] >> </span>close</code></pre>
|
|
<p>The required refactoring is implemented here with the help of the <a href="refactoring.html">Refactoring
|
|
Parsers</a> too.</p>
|
|
<table width="90%" border="0" align="center">
|
|
<tr>
|
|
<td colspan="2" class="table_title"><b>Summary of Confix Parser refactorings</b></td>
|
|
</tr>
|
|
<tr class="table_title">
|
|
<td width="40%"><b>You write it as:</b></td>
|
|
<td width="60%"><code><font face="Verdana, Arial, Helvetica, sans-serif">It
|
|
is refactored to:</font></code></td>
|
|
</tr>
|
|
<tr>
|
|
<td width="40%" class="table_cells"><code>confix_p<span class="special">(</span><span class=identifier>open</span><span class="special">,</span>
|
|
expr<span class="special">,</span> close<span class="special">)</span></code></td>
|
|
<td width="60%" class="table_cells"> <p><code>open <span class=special>>>
|
|
(</span>expr <span class=special>-</span> close<span class=special>)</span><font color="#0000FF">
|
|
</font><span class=special>>></span> close</code></p>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="40%" class="table_cells"><code>confix_p<span class="special">(</span><span class=identifier>open</span><span class="special">,</span>
|
|
expr<span class="special">[</span>func<span class="special">],</span> close<span class="special">)</span></code></td>
|
|
<td width="60%" class="table_cells"> <p><code>open <span class=special>>>
|
|
(</span>expr <span class=special>-</span> close<span class="special">)[</span>func<span class="special">]
|
|
<font color="#0000FF" class="special">>></font></span> close</code></p>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="40%" class="table_cells" height="9"><code>confix_p<span class="special">(</span><span class=identifier>open</span><span class="special">,
|
|
*</span>expr<span class="special">,</span> close<span class="special">)</span></code></td>
|
|
<td width="60%" class="table_cells" height="9"> <p><code>open <font color="#0000FF"><span class="special">>></span></font>
|
|
<span class="special"><font color="#0000FF" class="special">*</font>(</span>expr
|
|
<font color="#0000FF" class="special">-</font> close<span class="special">)
|
|
<font color="#0000FF" class="special">>></font></span> close</code></p>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="40%" class="table_cells"><code>confix_p<span class="special">(</span><span class=identifier>open</span><span class="special">,
|
|
(*</span>expr<span class="special">)[</span>func<span class="special">],
|
|
close</span><span class="special">)</span></code></td>
|
|
<td width="60%" class="table_cells"> <p><code>open <font color="#0000FF"><span class="special">>></span></font><span class="special">
|
|
(<font color="#0000FF" class="special">*</font>(</span>expr <font color="#0000FF" class="special">-</font>
|
|
close<span class="special">))[</span>func<span class="special">] <font color="#0000FF" class="special">>></font></span>
|
|
close</code></p>
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
<p><a name="comment_parsers"></a><b>Comment Parsers</b></p>
|
|
<p>The Comment Parser generator template <tt>comment_p</tt>
|
|
is helper for generating a correct <a href="#confix_parser">Confix Parser</a>
|
|
from auxiliary parameters, which is able to parse comment constructs as follows:
|
|
</p>
|
|
<pre><code> StartCommentToken <span class="special">>></span> Comment text <span class="special">>></span> EndCommentToken</code></pre>
|
|
<p>There are the following types supported as parameters: parsers, single
|
|
characters and strings (see as_parser). If it
|
|
is used with one parameter, a comment starting with the given first parser
|
|
parameter up to the end of the line is matched. So for instance the following
|
|
parser matches C++ style comments:</p>
|
|
|
|
<pre><code><span class=identifier> comment_p</span><span class=special>(</span><span class=string>"//"</span><span class=special>)</span></code></pre>
|
|
<p>If it is used with two parameters, a comment starting with the first parser
|
|
parameter up to the second parser parameter is matched. For instance a C style
|
|
comment parser could be constrcuted as:</p>
|
|
<pre><code> <span class=identifier>comment_p</span><span class=special>(</span><span class=string>"/*"</span><span class=special>, </span><span class=string>"*/"</span><span class=special>)</span></code></pre>
|
|
<p>The <tt>comment_p</tt> parser generator allows to generate parsers for matching
|
|
non-nested comments (as for C/C++ comments). Sometimes it is necessary to parse
|
|
nested comments as for instance allowed in Pascal.</p>
|
|
<pre><code class="comment"> { This is a { nested } PASCAL-comment }</code></pre>
|
|
<p>Such nested comments are
|
|
parseable through parsers generated by the <tt>comment_nest_p</tt> generator
|
|
template functor. The following example shows a parser, which can be used for
|
|
parsing the two different (nestable) Pascal comment styles:</p>
|
|
<pre><code> <span class=identifier>rule</span><span class=special><> </span><span class=identifier>pascal_comment
|
|
</span><span class=special>= </span><span class=identifier>comment_nest_p</span><span class=special>(</span><span class=string>"(*"</span><span class=special>, </span><span class=string>"*)"</span><span class=special>)
|
|
| </span><span class=identifier>comment_nest_p</span><span class=special>(</span><span class=literal>'{'</span><span class=special>, </span><span class=literal>'}'</span><span class=special>)
|
|
;</span></code></pre>
|
|
<p>Please note, that a comment is parsed implicitly as if the whole <tt>comment_p(...)</tt>
|
|
statement were embedded into a <tt>lexeme_d[]</tt> directive, i.e. during parsing
|
|
of a comment no token skipping will occur, even if you've defined a skip parser
|
|
for your whole parsing process.</p>
|
|
<p> <img height="16" width="15" src="theme/lens.gif"> <a href="../example/fundamental/comments.cpp">comments.cpp</a> demonstrates various comment parsing schemes: </p>
|
|
<ol>
|
|
<li>Parsing of different comment styles </li>
|
|
<ul>
|
|
<li>parsing C/C++-style comment</li>
|
|
<li>parsing C++-style comment</li>
|
|
<li>parsing PASCAL-style comment</li>
|
|
</ul>
|
|
<li>Parsing tagged data with the help of the confix_parser</li>
|
|
<li>Parsing tagged data with the help of the confix_parser but the semantic<br>
|
|
action is directly attached to the body sequence parser</li>
|
|
</ol>
|
|
<p>This is part of the Spirit distribution.</p>
|
|
<table border="0">
|
|
<tr>
|
|
<td width="10"></td>
|
|
<td width="30"><a href="../index.html"><img src="theme/u_arr.gif" border="0"></a></td>
|
|
<td width="30"><a href="character_sets.html"><img src="theme/l_arr.gif" border="0"></a></td>
|
|
<td width="30"><a href="list_parsers.html"><img src="theme/r_arr.gif" border="0"></a></td>
|
|
</tr>
|
|
</table>
|
|
<br>
|
|
<hr size="1">
|
|
<p class="copyright">Copyright © 2001-2002 Hartmut Kaiser<br>
|
|
<br>
|
|
<font size="2">Use, modification and distribution is subject to the Boost Software
|
|
License, Version 1.0. (See accompanying file LICENSE_1_0.txt or copy at
|
|
http://www.boost.org/LICENSE_1_0.txt) </font> </p>
|
|
</body>
|
|
</html>
|