[PATCH v3 2/9] parse-time-string: add a date/time parser to notmuch
Jani Nikula
jani at nikula.org
Mon Sep 17 08:54:23 PDT 2012
On Mon, 17 Sep 2012, Michal Nazarewicz <mina86 at 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 “totally unreadable” 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=devel/sparse/sparse.git
More information about the notmuch
mailing list