Return-Path: Delivered-To: apmail-lucene-java-dev-archive@www.apache.org Received: (qmail 86702 invoked from network); 25 Sep 2009 13:59:13 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 25 Sep 2009 13:59:13 -0000 Received: (qmail 20613 invoked by uid 500); 25 Sep 2009 13:59:12 -0000 Delivered-To: apmail-lucene-java-dev-archive@lucene.apache.org Received: (qmail 20531 invoked by uid 500); 25 Sep 2009 13:59:12 -0000 Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: java-dev@lucene.apache.org Delivered-To: mailing list java-dev@lucene.apache.org Received: (qmail 20523 invoked by uid 99); 25 Sep 2009 13:59:12 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 25 Sep 2009 13:59:12 +0000 X-ASF-Spam-Status: No, hits=3.4 required=10.0 tests=HTML_MESSAGE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [208.97.132.177] (HELO homiemail-a15.g.dreamhost.com) (208.97.132.177) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 25 Sep 2009 13:59:02 +0000 Received: from [10.0.0.77] (adsl-065-013-152-164.sip.rdu.bellsouth.net [65.13.152.164]) by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPA id 5F4B176C070 for ; Fri, 25 Sep 2009 06:58:41 -0700 (PDT) From: Grant Ingersoll Content-Type: multipart/alternative; boundary=Apple-Mail-675-702013837 Subject: Query Parsing was Fwd: Lab - Esqueranto Date: Fri, 25 Sep 2009 09:58:40 -0400 References: <499888440908171709i4272f97u51f1baf1902decb5@mail.gmail.com> To: java-dev@lucene.apache.org Message-Id: <68A683AF-0050-495D-B08D-C02D93927CAB@apache.org> Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) X-Virus-Checked: Checked by ClamAV on apache.org --Apple-Mail-675-702013837 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Has anyone looked/used Antlr for Query Parser capabilities? There was some discussion over at Apache Labs that might bear discussing in light of our new Query Parser contrib. Begin forwarded message: > From: Tim Williams > Date: August 17, 2009 8:09:04 PM EDT > To: labs@labs.apache.org > Subject: Re: Lab - Esqueranto > Reply-To: labs@labs.apache.org > > On Mon, Aug 17, 2009 at 7:00 PM, Grant > Ingersoll wrote: >> >> On Aug 2, 2009, at 1:43 PM, Tim Williams wrote: >>> >>> Hi Martin, >>> Sure, if it works like I envision it, Lucene would just be *one* >>> concrete tree grammar implementation - there could be others (ie >>> OracleText), I'm thinking it is broader than one implementation - >>> otherwise, I reckon it's Yet Another Lucene Query Parser (YALQP). >>> >>> For more practical reasons, I'm not a Lucene committer and it'd be >>> slow going to play around with this through JIRA patches to their >>> sandbox. >> >> FWIW, Lucene has recently added a new, more flexible Query Parser >> that >> allows for separation of the various pieces (syntax, intermediate >> representation, Lucene Query). You might want to check it out and >> see how >> that fits > > Thanks Grant, yeah I've looked at that and it seems really (overly?) > complex for what I'm trying to achieve. It seems to re-implement much > of the goodness that antlr provides for free. For example, with antlr > I already get a lexer/parser grammar separate from the tree grammar. > So, to plug in a new parser syntax is trivial - just implement a new > lexer/parser grammar that provides tree rewrites consistent with a > lucene tree grammar. Conversely, to implement a new concrete > implementation, just implement a new tree grammar for the existing > lexer/parser grammar. > > Of course, maybe I'll get down this road and realize how naive my path > is and just switch over. For now, just looking at a query parser > that, by itself, is approaching the size of the lucene core code base > is intimidating:) Thanks for the pointer though, I'm subscribed over > there and keep an eye out for progress on the new parser.... > > Thanks, > --tim > > --------------------------------------------------------------------- > To unsubscribe, e-mail: labs-unsubscribe@labs.apache.org > For additional commands, e-mail: labs-help@labs.apache.org > --Apple-Mail-675-702013837 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Has = anyone looked/used Antlr for Query Parser capabilities?  There was = some discussion over at Apache Labs that might bear discussing in light = of our new Query Parser contrib.

Begin forwarded = message:

From: Tim Williams <williamstw@gmail.com>
Date: August 17, 2009 = 8:09:04 PM EDT
To: labs@labs.apache.org
Subject: Re: Lab - = Esqueranto
Reply-To: labs@labs.apache.org

On Mon, Aug 17, 2009 at 7:00 PM, Grant Ingersoll<gsingers@apache.org> = wrote:

On Aug 2, 2009, at 1:43 PM, Tim Williams = wrote:

Hi = Martin,
Sure, if it works like I envision it, Lucene would just = be *one*
concrete tree grammar = implementation - there could be others = (ie
OracleText), I'm thinking it is broader than one = implementation -
otherwise, I reckon it's Yet = Another Lucene Query Parser = (YALQP).

For more practical reasons, I'm = not a Lucene committer and it'd = be
slow going to play around with this through JIRA patches = to their
sandbox.

FWIW, Lucene = has recently added a new, more flexible Query Parser = that
allows for separation of = the various pieces (syntax, intermediate
representation, Lucene Query).  You might want to = check it out and see how
that = fits

Thanks Grant, yeah I've looked at that and it = seems really (overly?)
complex for what I'm trying to achieve. =  It seems to re-implement much
of the goodness that antlr = provides for free.  For example, with antlr
I already get a = lexer/parser grammar separate from the tree grammar.
So, to plug in a = new parser syntax is trivial - just implement a new
lexer/parser = grammar that provides tree rewrites consistent with a
lucene tree = grammar.  Conversely, to implement a new = concrete
implementation, just implement a new tree grammar for the = existing
lexer/parser grammar.

Of course, maybe I'll get down = this road and realize how naive my path
is and just switch over. =  For now, just looking at a query parser
that, by itself, is = approaching the size of the lucene core code base
is intimidating:) =  Thanks for the pointer though, I'm subscribed over
there and = keep an eye out for progress on the new = parser....

Thanks,
--tim

--------------------------------= -------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@labs.apa= che.org
For additional commands, e-mail: labs-help@labs.apache.org


= --Apple-Mail-675-702013837--