From: Jani Nikula <jani@nikula.org>
To: Michal Nazarewicz <mina86@mina86.com>, notmuch@notmuchmail.org,
	David Bremner <david@tethera.net>
Subject: Re: [PATCH v3 2/9] parse-time-string: add a date/time parser to
	notmuch
In-Reply-To: <xa1tpq5kzqi8.fsf@mina86.com>
References: <cover.1347484177.git.jani@nikula.org>
	<89741ec9a9687fca8b30aa1a4877392d355dd3ce.1347484177.git.jani@nikula.org>
	<xa1tvcfidvpe.fsf@mina86.com> <878vcerurc.fsf@nikula.org>
	<xa1tpq5kzqi8.fsf@mina86.com>
User-Agent: Notmuch/0.14+29~g77c762c (http://notmuchmail.org) Emacs/23.3.1
	(i686-pc-linux-gnu)
Date: Mon, 17 Sep 2012 18:54:23 +0300
Message-ID: <87wqzsfxw0.fsf@nikula.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: list

On Mon, 17 Sep 2012, Michal Nazarewicz <mina86@mina86.com> wrote:
> Bison can do a lot of weird stuff including modifying how lexer
> interpretes tokens even while parsing given grammar rule.

I'll just have to take your word for it.

> I'm sorry.  I sometime tend to go into extremes with my statements, so
> yes, the =E2=80=9Ctotally unreadable=E2=80=9D was a over statement on my =
part.

Okay.

> My point was however that parsing is a solved problem, and for
> non-trivial parsers one needs to ask herself whether it's worth trying
> to implement the logic, or maybe using a parser generator is just
> simpler.

If there's something non-trivial about parsing dates and times, it's not
the actual parsing. It's not a well defined grammar. And judging by the
number of date parsers available that would be suitable for notmuch, as
a library, parsing dates is not a solved problem.

> And in this particular case, my feeling is that bison is easier to read
> and modify.
>
> To add some merit to my statement, I attach a bison parser.

And there are people out there writing compilers without a parser
generator... [1] But using a parser generator or not is really not the
issue here, whichever has more merit. The issue is adding suitable date
range queries to notmuch.

I have submitted patches to do just that. I don't intend to rework them
much anymore. It's always interesting in the beginning, but adding the
last bits of polish and fixing the corner cases can get a bit
tedious. You know how it is. At this point, I'd just like to have the
feature in notmuch.

So I don't know. I guess I want to say, please submit patches to add the
feature, with polish, and not to prove a point, damnit. I have no issues
with promoting whichever approach is the best in the end.


BR,
Jani.


[1] http://git.kernel.org/?p=3Ddevel/sparse/sparse.git