From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alexandre Garreau Newsgroups: gmane.emacs.devel Subject: Re: sqlite3 Date: Mon, 06 Dec 2021 16:34:14 +0100 Message-ID: <21213494.XK775qdTfN@galex-713.eu> References: <87tufmjyai.fsf@gnus.org> <0CE6937B-62E5-4C15-8B8C-1DDC0166ACF5@mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1618"; mail-complaints-to="usenet@ciao.gmane.io" To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Dec 06 16:35:54 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1muG1w-00006p-Px for ged-emacs-devel@m.gmane-mx.org; Mon, 06 Dec 2021 16:35:52 +0100 Original-Received: from localhost ([::1]:44828 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1muG1v-0006Q3-4S for ged-emacs-devel@m.gmane-mx.org; Mon, 06 Dec 2021 10:35:51 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:42654) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1muG0W-0005cI-Rf for emacs-devel@gnu.org; Mon, 06 Dec 2021 10:34:25 -0500 Original-Received: from [2a00:5884:8305::1] (port=44138 helo=galex-713.eu) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1muG0U-000513-Hr for emacs-devel@gnu.org; Mon, 06 Dec 2021 10:34:24 -0500 Original-Received: from gal by galex-713.eu with local (Exim 4.94.2) (envelope-from ) id 1muG0M-0024QM-Nh for emacs-devel@gnu.org; Mon, 06 Dec 2021 16:34:14 +0100 In-Reply-To: X-Host-Lookup-Failed: Reverse DNS lookup failed for 2a00:5884:8305::1 (failed) Received-SPF: pass client-ip=2a00:5884:8305::1; envelope-from=galex-713@galex-713.eu; helo=galex-713.eu X-Spam_score_int: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.1 / 5.0 requ) BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:281126 Archived-At: Le lundo, 6-a de decembro 2021, 14-a horo kaj 8:48 CET Stefan Kangas a=20 =C3=A9crit : > Qiantan Hong writes: >=20 >=20 >=20 > > I really don=E2=80=99t like the idea of introducing an external UNIX-y > > dependency that significantly overlaps with Emacs Lisp itself, > > it=E2=80=99s almost like saying =E2=80=9Clet=E2=80=99s make Emacs progr= ammable using > > JavaScript, because JavaScript is faster, safer, etc etc=E2=80=9D. >=20 > I don't see any similarity between Lars' suggestion and the idea of > introducing a new language to rival Emacs Lisp. SQL is a full-fleged logical language akin to prolog: the comparison is=20 very sound. Because then will arrive the same tradeoff occurs than in most= =20 modern webapps: whenever you interface with persistent I/O you start=20 thinking =E2=80=9Cshould that algorithm/datastructure be coded in SQL or ?=E2=80=9D, and the right answer is almost always SQL because that= will=20 give more freedom to planning, reorganization, optimization, etc. the situation would be different if there was a powerful and efficient and= =20 free implementation of sql in lisp (postgres at the beginning almost=20 became one but early changed direction toward C, which is more understood=20 and causes less disagreement). > > We don=E2=80=99t need the sql language. In most cases it=E2=80=99s no b= etter than > > MAPCAR-ing and FILTER-ing, and it=E2=80=99s strictly no better than just > > embedding a Prolog interpreter in Emacs Lisp. >=20 > AFAIU, the idea is to hide away any SQL inside a new sqlite.el that will > provide some ORM. I don't see this as fundamentally different to > depending on gdbm, or indeed any other store, which presumably also > would not be programmable directly in Emacs Lisp. gdbm could be a fully compatible backend for the exact same usage and=20 interface as sqlite. but that would mean purposedly limiting the power=20 and expressiveness provided by sqlite. people would want to circumvent=20 that.