<p>Respected sir,</p>
<p>I have made several changes in the proposal.</p>
<p>- Now I have not ruled out the idea of tool generated parser.</p>
<p>- Regarding time-line I had already proposed weekly report submission. Now I have written a much detailed time-line.</p>
<p>- I have made several other changes. Please go through it at once.</p>Looking forward to hear from you<br><br>Thanking you<br><br>Saurabh Kumar<br><br><div class="gmail_quote">On Fri, Apr 1, 2011 at 2:40 AM, saurabh kumar <span dir="ltr"><<a href="mailto:saurabh.catch@gmail.com">saurabh.catch@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Respected sir,<br><br><div>
I have submitted my proposal on gsoc-melange site.</div><div>Please have a look and suggest some improvements.<br><br>Meanwhile I am spending time understanding the source code <br>of query parser class from xapian-core.<br>
<br>Looking forward for your comments on my proposal.<br></div><div><br></div><div>Thanking you</div><div>Saurabh Kumar</div><div><div></div><div class="h5"><br><br><br><div class="gmail_quote">On Thu, Mar 31, 2011 at 8:38 AM, Olly Betts <span dir="ltr"><<a href="mailto:olly@survex.com" target="_blank">olly@survex.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Thu, Mar 31, 2011 at 01:30:30AM +0530, saurabh kumar wrote:<br>
> I have some doubts :<br>
><br>
> 1) Why is using the tools like yacc, bison not a good approach? Can you<br>
> illustrate with an example?<br>
<br>
</div>The parser needs to be forgiving, since the input is typed by (often<br>
non-technical) humans. The input isn't expected to be program code, and<br>
"Syntax Error" is rarely an acceptable response (better to correct the<br>
query and say "Searched for 'XXX' instead", with a "Did you mean 'YYY'?"<br>
is there's an alternative plausible fix up).<br>
<br>
Good error recovery in generated parsers is hard to do well, and usually<br>
results in adding extra rules to the parser description, and that<br>
obfuscates what we're actually trying to do.<br>
<br>
The grammar is also not something we can always restrain in ways to suit<br>
the parser generator.<br>
<br>
For a formally specified grammar (like a language standard perhaps),<br>
there's usually a BNF description of the grammar rules, so it's handy<br>
to have the parser description mirror it. That's not the case here.<br>
<br>
Currently the lexer does things like tracking the "mode", which is<br>
really an indication of where in the grammar we are.<br>
<div><br>
> 2) In the proposed project are we NOT going to use any tools like YACC etc.?<br>
<br>
</div>Well, you're welcome to propose what you like, but you'll need to do<br>
a harder sell on this one.<br>
<br>
If you want to use a parser generator, we currently use lemon, which has<br>
a clearer syntax than bison/yacc, and is structured such that the lexer<br>
calls the parser (rather than the parser calling the lexer, as in<br>
bison/yacc). That allows the lexer to be simpler, since it doesn't need<br>
to "keep its place" with explicit state. So I'd suggest we probably<br>
don't want to move back to using bison (one reason we moved away<br>
originally was the lack of reentrancy in bison-generated parser, but<br>
that at least now seems to have been addressed).<br>
<div><br>
> Should I mail my proposal to the mailing list or just submit it at google<br>
> SOC site? Because certainly I would require your<br>
> comments to improve upon the first draft.<br>
<br>
</div>Just submit it to the site - we can comment there and you can revise it<br>
up until the deadline (April 8th, 19:00 UTC).<br>
<br>
Cheers,<br>
<font color="#888888"> Olly<br>
</font></blockquote></div><br>
</div></div></blockquote></div><br>