lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Kurz <>
Subject Re: [lucy-dev] Host QueryParser reimplementations
Date Sat, 23 Apr 2011 22:44:07 GMT
On Mon, Apr 18, 2011 at 12:39 PM, Marvin Humphrey
<> wrote:
> On Fri, Apr 15, 2011 at 10:27:28PM -0500, Peter Karman wrote:
>> I think the focus on reliable, flexible *Query classes has been a good design
>> choice to date, because it means that it is quite straightforward to roll your
>> own query parser (as I have done), entirely suited to your application's needs,
>> sidestepping the Lucy QueryParser altogether. That's good library design, imo.
> Perhaps we can build on that foundation.

I've been disagreeing with a number of things lately, but this one I
strongly agree with:  it's great to have an easy to create and well
defined data structure which serves as the canonical representation of
what a user wishes to search for!  So long as this is clear and easy
to create, it doesn't really matter how extensible the built in parser

> I'm thinking of starting a project at, with the working
> title "LucyX::Search::HostQueryParser".  Its primary purpose would be to
> supply hackable reimplementations of Lucy::Search::QueryParser in the host
> language, typically using a parser generator -- Parse::RecDescent for Perl,
> maybe pyparsing for Python, etc.

Sounds like a good idea.  My only question would be whether "LucyX" is
the right namespace for this.  I've never particularly liked it as a
name, and once we have multiple people contributing it doesn't really
make a difference whether they are stomping on each others "Lucy"
objects or "LucyX" objects.  I wonder whether just "Lucy::Perl::*",
"Lucy::Python::*" might be clearer.  But no strong objection.


View raw message