From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philip Kaludercic Newsgroups: gmane.emacs.devel Subject: Re: [NonGNU ELPA] New package: sqlite3 Date: Wed, 22 Mar 2023 08:00:23 +0000 Message-ID: <87mt455i7c.fsf@posteo.net> References: <87cz5o6csk.fsf@bernoul.li> <87mt4swxsw.fsf@posteo.net> <875ybd7mbh.fsf@bernoul.li> <87y1nzb95o.fsf@posteo.net> <87y1nq5pkz.fsf@posteo.net> <871qlhdefq.fsf@logand.com> <875yatn70c.fsf@posteo.net> <87v8itbu49.fsf@logand.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22676"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Lynn Winebarger , emacs-devel@gnu.org To: Tomas Hlavaty Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Mar 22 09:01:01 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 1petP3-0005iN-2A for ged-emacs-devel@m.gmane-mx.org; Wed, 22 Mar 2023 09:01:01 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1petOD-0008Dy-W8; Wed, 22 Mar 2023 04:00:10 -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 1petO8-0008DU-Gz for emacs-devel@gnu.org; Wed, 22 Mar 2023 04:00:04 -0400 Original-Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1petO6-0006wb-3B for emacs-devel@gnu.org; Wed, 22 Mar 2023 04:00:04 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id DA89D24031F for ; Wed, 22 Mar 2023 08:59:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1679471999; bh=muZwxlSzK1mrNQopvqeuXVQdtdSAfOA+mqphN+A/y8g=; h=From:To:Cc:Subject:Date:From; b=HTOD62SJ4X9380nAiWDEPdCE6Qlx8hG9faKlhPwMKONqR6Zi6FD6YMUhJ0Ou0E7Jt ArQUZcC7CjE5dk54dN5rJquY5gxZWj0aOxNfdqzBz8fKxonBJhd3kPLgs0BK9A5RwJ bg0Y+eE97V/9wNF/WwYRcdn4HnHUhi6pPwYuqv6E/w5mKxmyAtVqGHbCaJ0NMtfkRa Y1At0BwxUROmGZz/4O2jZwvVm8sT/MFpxzBtEGZfLStKPXcdOJAP8XezC+eui5DpuL lCXNun6NWvW5x4oS/BZJs6h8pvS8FvXctQMgDToCXTWc7S5HGBaUfJtmjmqcVmMhUg +WbbcKxix2PXQ== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4PhLVR2KjWz9rxM; Wed, 22 Mar 2023 08:59:59 +0100 (CET) In-Reply-To: <87v8itbu49.fsf@logand.com> (Tomas Hlavaty's message of "Tue, 21 Mar 2023 23:46:30 +0100") Received-SPF: pass client-ip=185.67.36.65; envelope-from=philipk@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, 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:304694 Archived-At: Tomas Hlavaty writes: > On Tue 21 Mar 2023 at 21:12, Philip Kaludercic wrote: >>>> To me the >>>> advantage of something like `rx' is that I can insert comments and make >>>> use of regular indentation. >>> >>> Those are cosmetic advantages. >>> There are more profound advatages. >> >> In what way profound? > > For example, the Lisp environment provides many tools that understand > and help with lisp code (jumping, help, autodoc, compilation, warnings, > errors debugging etc). With strings, one cannot take advantage of any > those. Another: making sure that things have the right structure, make > sense to some extent and output is properly escaped. It is also much > easier to process or transform such cons tree than process or transform > a string with some kind of syntax. It might be easier, but it certainly possible to have the tools that take advantage of lisp code also understand specific strings. This is not what I would call "profound". >> Tomas Hlavaty writes: >>> On Tue 21 Mar 2023 at 16:53, Philip Kaludercic wrote: >>>> I really, really have no idea what you are getting at. As in "ok, but >>>> 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? >>> >>> The idea is that one should not concatenate strings by hand but one >>> should write the query as sexp (likely build that cons tree using quote >>> or backquote). That cons tree should then be converted to string by a >>> lisp function. Only after that should the string be passed to sqlite. >>> >>> sexp (cons tree) -> string -> sqlite >> >> I was under the impression that Lynn was advocating for avoiding the >> usage any strings. In general this is nice and I'd use it if built-in, >> but seeing as SQL is more readable than regular expressions I am not >> under the impression that there is the same need for it. > > The point is that it is better to use an sexp based syntax than string > based syntax in both cases, for sql and for regular expressions. This > is a general idea, one can apply it to html, css, xml, pdf, docx, xlsx, > ooxml etc. anywhere where one needs to output some kind of arbitrary > (non-sexp based) syntax. > > The fact that in the end a string is passed to sqlite is not > interesting. Interesting is that one writes sql not by concatenating > strings but by building cons trees, similar to what one does when > writing lisp code. I agree that we should strings ought not to be concatenated. My issue is that I am under the impression that constructing SQL statements from s-expressions is more complicated than it is to construct regular expressions, and I don't know if it is worth the effort or if parameterised queries suffice?