Mailing-List: contact lucy-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: lucy-dev@lucene.apache.org
Received-SPF: pass (asf.osuosl.org: domain of dbalmain.ml@gmail.com designates
 64.233.166.183 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=h01OPRkRmfW+wVBQs3onFKzECvrkWrfPLlP9HSgJ425ib8h3xyvE2EraqReYboVwbd2N4yxz7ZsHMyBUCJRMlJsTBd5C+pSl81S/BrV9yPfN7NUyoDTnwvI46akZ4eMQCdcKdINKZHHX2snMj4OCKyyKWNZ2qrsxsv0QOeCaz1A=
Message-ID: <d792e0dc0607052129n6791b999v8f3737c1a9ae3895@mail.gmail.com>
Date: Thu, 6 Jul 2006 13:29:49 +0900
From: "David Balmain" <dbalmain.ml@gmail.com>
To: lucy-dev@lucene.apache.org
Subject: Re: Charmonizer
In-Reply-To: <DC99D775-50BE-4100-91EA-4238C5E45B8D@rectangular.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <DC99D775-50BE-4100-91EA-4238C5E45B8D@rectangular.com>

On 7/5/06, Marvin Humphrey <marvin@rectangular.com> wrote:
> Greets,
>
> I've finished a provisional implementation of the project I
> originally proposed as "Configurator".  Turns out the name
> "Configurator", which I suspected would be relatively rare -- it is a
> bastardization after all -- is just ridiculously common.  So, new
> name: Charmonizer.  (Which I pronounce charm-uh-nizer, rather than
> see-harmonizer.)  8 Google hits to 13,700,000, and more descriptive
> of what it does anyway.
>
> The implementation uses a domain-specific language, as per Dave's
> suggestion.  The syntax is quite crude, so that a heavy-duty
> recursive descent parser won't be needed.  For the language
> description, see the README file, near the bottom of the patch.
>
> Comments?  Commit it then refine, or hold off?

I like it. This is exactly what I had in mind. Go ahead and commit it.

> I've haven't prepared any unit tests, since I wanted to get this out
> of the lab, but we'll definitely need a battery for each interpreter
> implementation.

I agree. I'll try and write a ruby interpreter asap.