Re: Early preview of s-expression based query parser

Subject: Re: Early preview of s-expression based query parser

Date: Sun, 18 Jul 2021 16:43:02 -0300

To: Hannu Hartikainen, notmuch@notmuchmail.org

Cc:

From: David Bremner


Hannu Hartikainen <hannu.hartikainen@gmail.com> writes:

>
> But looking at the sexp parser and the implementation of logical
> connectors I can't help but think that isn't this patchset implementing
> a tiny subset of a lisp? And wouldn't a full embedded lisp be much, much
> more powerful?

I think the analogy here is between JSON, and JavaScript. Plenty of
programs find it useful to use JSON as an input format without embedding
JavaScript. That's not just because JavaScript is not everyone's
favourite programming language, but because a Turing complete input
language is a mixed blessing.

> I'd at least consider embedding something like s7 [0] or Janet [1],
> writing bindings for enough Xapian functionality, and then writing the
> rest in the lisp itself. That way you'd get a more powerful and
> extensible sexp implementation, and you'd implement most of it in a much
> more ergonomic language.

Since what I want to do is actually a fairly thin layer on top of the
Xapian API, it's not clear that writing the bindings would be less code
than the roughly 450 lines of C/C++ needed to parse the s-expressions.

We already face challenges maintaining bindings for Python and Ruby; I
suspect that finding people to work on bindings for fairly obscure
(defined by not being in Debian) lisp variants would not be easier.
Ditto for coding in said lisp in the notmuch core.

> Of course I don't really know Xapian and I'm not sure of the design
> goals of this sexp parser, but my experience with HoneySQL [2] tells me
> that building queries with a lisp from lisp data structures can be
> unbelievably powerful.

Sure, and one of the motivations is to be able to conveniently build
queries in emacs lisp (some other lisp would obviously work just as
well).

If someone wants to take on a more ambitious project involving a full
lisp, that probably makes the most sense as a client project that links
to notmuch. That leaves someone free to explore without waiting on our
somewhat ponderous development cycle.

d
_______________________________________________
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-leave@notmuchmail.org

Thread: