From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Lynn Winebarger Newsgroups: gmane.emacs.devel Subject: Re: [NonGNU ELPA] New package: sqlite3 Date: Wed, 22 Mar 2023 20:07:27 -0400 Message-ID: References: <87cz5o6csk.fsf@bernoul.li> <87mt4swxsw.fsf@posteo.net> <875ybd7mbh.fsf@bernoul.li> <87y1nzb95o.fsf@posteo.net> <87y1nq5pkz.fsf@posteo.net> <87ttye5mcw.fsf@posteo.net> <87mt46nj00.fsf@posteo.net> <87ilet5hq0.fsf@posteo.net> 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="35825"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel To: Philip Kaludercic Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Mar 23 01:08:06 2023 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 1pf8Uv-00090n-9b for ged-emacs-devel@m.gmane-mx.org; Thu, 23 Mar 2023 01:08:05 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pf8Ua-0002bV-67; Wed, 22 Mar 2023 20:07:44 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pf8UY-0002Xl-8p for emacs-devel@gnu.org; Wed, 22 Mar 2023 20:07:42 -0400 Original-Received: from mail-pl1-x62c.google.com ([2607:f8b0:4864:20::62c]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pf8UW-0000CT-Ep for emacs-devel@gnu.org; Wed, 22 Mar 2023 20:07:41 -0400 Original-Received: by mail-pl1-x62c.google.com with SMTP id ja10so20793556plb.5 for ; Wed, 22 Mar 2023 17:07:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679530059; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=B5yBSj+uk9KVKER/exYKxSZpKSS35buYXSDq8UgbHIA=; b=g2gH4umLTLMAznLSRGqcnhYkCUk9cOGTauC/tyk3ODLOk3dXA7isZJe5IlqdlesKWN CrB+suXxvIxCmosPa6fSQdQ4pjCXnyFSMq7Ks//SyWnAYEQl8kpTMBNeOA5YdMVJuR1j bOzn7H+PrwK61Ohnofq24xJA+zxEba0ZVSD1Xq6LddGTQh+lm6P+FjzKbX+3NWXUmwe0 q/uIPHspPJYarEkyryQkfcs4zrkUIKJcIY5baq3/9GYBRIfekjZHLrAsJt4rCbRgLF7K Wvds4tByU8lvNEFLBxYJqYWUZzQnMqfv2wUQWVsmh+cNjcn+WKbvEXYQJ7MUzBDrs17p 0zgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679530059; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=B5yBSj+uk9KVKER/exYKxSZpKSS35buYXSDq8UgbHIA=; b=XGZi3Xw+1tW9/zFt2UaaLuYAPwmh7+j0f6gQuK2OgAh2677doMGO6E3ix39drewVh4 q4jlaBukGBTZlNfllsEmjDjmZYxhAKa0Mgmpz22+c7JMA7JK/eJPlMIzWifPTbuAu46m 0wvZ1JohKdTt25hfd4svbAdICO5PuWxo2gKpTsAd4BtOZuZQR4UUge42ciR0OhCeFR+Y QEG9C2eIN/2R0hjmoBHIdrd3JApsctDziZxVCQ308o2a6apYBkORP3UWQyJihqkNVYah wKh2b+8474oj8EgyhP5E7IRE+OIQWujO8t9GjCfiMjjET6RjX7W5JdrQKWgujXIkDFMb igPg== X-Gm-Message-State: AO0yUKVn5Qrr5uBfgLThKOk7kKTM3AGMqJMBRWDdk2jnjxc3z7AgwOhk xyfoqU1Ih5GPZ5suvpuj2A1PatpT2i8aSTrQbwM= X-Google-Smtp-Source: AK7set/r8JE+s0tY6rU5S2/bcpRPC4peDSPF7OJfYrbMogKwlWuD4ZCfEYNjJX/4oNLYqHjPZKmQLF4pWruDoAWCKN4= X-Received: by 2002:a17:90a:e547:b0:23c:fd83:1bbb with SMTP id ei7-20020a17090ae54700b0023cfd831bbbmr1731959pjb.8.1679530059136; Wed, 22 Mar 2023 17:07:39 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::62c; envelope-from=owinebar@gmail.com; helo=mail-pl1-x62c.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:304726 Archived-At: On Wed, Mar 22, 2023 at 11:05=E2=80=AFAM Lynn Winebarger wrote: > > On Wed, Mar 22, 2023, 4:10 AM Philip Kaludercic wrot= e: >> >> Lynn Winebarger writes: >> >> > On Tue, Mar 21, 2023 at 12:53=E2=80=AFPM Philip Kaludercic wrote: >> >> I really, really have no idea what you are getting at. As in "ok, bu= t >> >> what is your intent in explaining this?". >> >> >> >> Are you trying to propose that Emacs circumvents the SQLite API (that= as >> >> far as I see uses strings) by constructing statement objects manually= ? >> > >> > Not at all. I don't think I can communicate via email the power of >> > generative programming techniques, and why basing them on simple >> > string concatenation is a bad idea, so I'm going to stop trying. >> >> I get that, and I am not advocating for string concatenation. Perhaps >> that is what is confusing me? >> >> > I don't think "? ? table values ( 1.0, 'Foo' )" can be supplied with >> > 'insert and 'into as parameters. >> >> Nor do I, but I doubt the necessity. SQL is a very brittle language, >> and replacing one keyword with another will usually require other >> changes to be made as well. > > > Exactly the point of a DSL that compiles to a query. > > Whether emacsql is the best DSL or not, I don't know. I really haven't u= sed it. It has the distinct advantage of existing and providing a syntax t= ree of the query, which are strong points. > I gave this some more thought after starting to sketch a sql sexpr -> string compiler. SQL is non-compositional (as you put it, "brittle"), so just encoding SQL syntax trees as sexprs is not particularly empowering. A lot of the ugliness (non-compositionality) arises from embedding properties of the expected instantiation of tables (e.g. keys, indexing) as part of the query. To get a compositional querying DSL, it's probably better to have three orthogonal but mutually recursive types of expressions, one for specifying the table schema, which may incorporate queries in its formation, which specify the shape of a table, and another for specifying "queries" (select - or just "from" as an operator, join, where, let ["with", as etc], labels ["with recursive"], etc) that will instantiate the data set in one form or another, and the third for "commands" that perform side-effects on the database. There's probably a set of these operators that can be cleanly composed in mostly arbitrary ways with clear semantics. Then those expressions could be compiled to SQL, letting the compiler handle optimization as dictated by experience. There's also the matter of how to store lisp data transparently in data tables. Storing pointers directly will mean the garbage collector will have to know which entries have LispObjects as values and how to trace them. And you wouldn't want to do that unless the database was in memory. I'm not going to put that before my other projects though, so I may just be using some fixed string queries to get things going with unboxed, which has fairly modest needs in terms of table schemas. Lynn