lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Hatcher <e...@ehatchersolutions.com>
Subject Re: suggestions for a student project
Date Thu, 27 May 2004 20:12:05 GMT
I would be happy with a *simpler* grammar that had less bells & 
whistles than the current QueryParser, and one that could take into 
account the new Query types (SpanQuery family and FilteredQuery).

There are so many oddities with the current QueryParser because it was 
designed to be the jack-of-all-trades kinda thing.  Thankfully 
QueryParser is subclassable to do things like prevent wildcard queries 
and do expected things with range queries.

The interactions with analysis and QueryParser make up the bulk of 
confusion with Lucene newbies, it seems.

Nutch has a simpler grammar, I believe.

	Erik



On May 27, 2004, at 3:47 PM, Jean-Francois Halleux wrote:

> I surely for one don't want to rewrite the parser but we have someone
> looking for a
> student project here :)
>
> There may be good reasons to hand code a parser I guess:
>
> http://gcc.gnu.org/gcc-3.4/changes.html
>
> says the C++ parser has been recoded by hand instead of using a parser
> generator.
>
> I am not sure at all maintainability would be worse. I have corrected 
> a few
> bugs in the current parser two-three months ago and this isn't what 
> you can
> call an easy task. Now I agree that correcting a parser or a grammar is
> probably never an easy task.
>
> Performance would probably be the same.
>
> Anyway, like you said, a good baseline for a comparison.
>
> -----Original Message-----
> From: Brian Goetz [mailto:brian@quiotix.com]
> Sent: jeudi 27 mai 2004 21:27
> To: Lucene Developers List; halleux.jf@skynet.be
> Subject: Re: suggestions for a student project
>
>
>> Done carefully, could it be worthwile to rewrite it from scratch 
>> without a
>> parser generator?
>
> I don't think that this would offer any improvement over the current
> parser for use in the Lucene project -- the maintainability would be
> worse, and the performance would probably be the same (and performacne
> of a query parser is almost irrelevant.) That said, if you really
> wanted to write a parser, it might be a useful baseline for comparing
> a rewritten parser -- the test cases include a number of specimen
> queries, so by comparing the results of the existing parser and your
> own, it would provide both a good "project target" and a baseline
> against which to test compliance.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: lucene-dev-help@jakarta.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: lucene-dev-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-dev-help@jakarta.apache.org


Mime
View raw message