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: Tue, 21 Mar 2023 16:53:35 +0000 Message-ID: <87mt46nj00.fsf@posteo.net> 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> 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="30269"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Jonas Bernoulli , emacs-devel@gnu.org To: Lynn Winebarger Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Mar 21 17:54:24 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 1pefFf-0007eb-MX for ged-emacs-devel@m.gmane-mx.org; Tue, 21 Mar 2023 17:54:23 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pefF7-0006Uz-IY; Tue, 21 Mar 2023 12:53:49 -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 1pefF2-0006Qp-9H for emacs-devel@gnu.org; Tue, 21 Mar 2023 12:53:44 -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 1pefEy-0000fb-SL for emacs-devel@gnu.org; Tue, 21 Mar 2023 12:53:42 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 667732404CD for ; Tue, 21 Mar 2023 17:53:37 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1679417617; bh=EhERQ1t4qgd7NmjlbrJII1Koq5Qa4Kv2XfRgo5GMOw0=; h=From:To:Cc:Subject:Autocrypt:Date:From; b=o644P1BD8HnRJv6WCNH0Tek2wu+9gJ01CLEXc1Gn7FfmXvmlijHyKjPWutyqHO0yx fo00DVNV2d0tRjjKkkR8Xhz9gs/3dA2UxSVP+jbkMr3cKMb7ATIPhYAbcotYfJaRc5 PoMGjgMnFft3e6cFdIlrjldP2EuzY8SxpPBVvXK1hHKxBnJQ7AMD9hr1+/39pDnn8V 18Z/xlXi39ddooJYTvwBGeHAEoEtq+hf17J1zKr6yDdvie+mZhFtRJllD5DaF0Z3hW KyAelsKz7BPXA6z7bveU0Oki3c9w9B4GOIfd6e+hku+9Ua8LDjbfmJwiuL9CLwEdbd Nyoih0elhaSRQ== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4PgyNc6SQzz9rxL; Tue, 21 Mar 2023 17:53:36 +0100 (CET) In-Reply-To: (Lynn Winebarger's message of "Tue, 21 Mar 2023 09:04:45 -0400") Autocrypt: addr=philipk@posteo.net; keydata= mDMEZBBQQhYJKwYBBAHaRw8BAQdAHJuofBrfqFh12uQu0Yi7mrl525F28eTmwUDflFNmdui0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiWBBMWCAA+FiEEDg7HY17ghYlni8XN8xYDWXahwukFAmQQUEICGwMFCQHhM4AFCwkI BwIGFQoJCAsCBBYCAwECHgECF4AACgkQ8xYDWXahwulikAEA77hloUiSrXgFkUVJhlKBpLCHUjA0 mWZ9j9w5d08+jVwBAK6c4iGP7j+/PhbkxaEKa4V3MzIl7zJkcNNjHCXmvFcEuDgEZBBQQhIKKwYB BAGXVQEFAQEHQI5NLiLRjZy3OfSt1dhCmFyn+fN/QKELUYQetiaoe+MMAwEIB4h+BBgWCAAmFiEE Dg7HY17ghYlni8XN8xYDWXahwukFAmQQUEICGwwFCQHhM4AACgkQ8xYDWXahwukm+wEA8cml4JpK NeAu65rg+auKrPOP6TP/4YWRCTIvuYDm0joBALw98AMz7/qMHvSCeU/hw9PL6u6R2EScxtpKnWof z4oM 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:304671 Archived-At: Lynn Winebarger writes: > On Tue, Mar 21, 2023 at 8:18=E2=80=AFAM Philip Kaludercic wrote: >> Lynn Winebarger writes: >> >> >> > * Treating code as data and vice-versa is a powerful programming te= chnique >> >> >> >> Not sure about this.... Strings are data too, but neither the SQL >> >> statements or the regular expressions are (Elisp) code. >> > >> > Are lisp macros written in terms of string interpolation? If there >> > are no other types of data than strings, fine, but that's not really >> > the case - machine instructions have different operations for >> > integers/floats/pointers, a good programming abstraction will reflect >> > that. If the underlying machine used strings to represent numbers and >> > arithmetic operations took two numeric strings and produced another >> > numeric string, maybe there'd be a case to be made (although the first >> > point above still mitigates against it). >> >> I really have no idea what you are getting at. > > The reason for not trying to construct SQL from strings (in macros or > other programmatic ways) is the same reason lisp and other dynamically > typed languages don't just treat every value as a string. The lisp > macro expander doesn't create a string to pass to eval - why would you > want to turn everything into a string for it to be parsed again, and > possibly introduce errors along the way? If I have a double that > happens to be expressible as an integer in text, will the system > ensure the generated query uses and returns values as doubles? > > If the machine only had string data types (I don't know how that would > work, it would be radically different from any architecture I'm > familiar with), then there would be an argument for only having > strings as primitive values, even in general purpose languages like > lisp. 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? >> >> To me the >> >> advantage of something like `rx' is that I can insert comments and ma= ke >> >> use of regular indentation. Then again, it would also be possible to >> >> provide specialised SQLite wrappers (sqlite-insert, sqlite-update, ..= .) >> >> instead of taking a `rx' like approach to generating strings. >> >> >> >> > The real power of embedding sqlite in elisp will come when sqlite d= ata >> >> > structures can be used as efficient representations of sets and >> >> > relations in lisp code. Eventually, I would also expect to see >> >> > mutually recursive code enabled, with "virtual table" modules for >> >> > emacs data structures so they can be transparently used in sql code, >> >> > along with sql functions written in lisp. For example, you might >> >> > create a table from lisp data using a select statement rather than >> >> > executing a large number of insert statements. In-memory databases >> >> > would not be unusual, and should be dumpable objects. >> >> >> >> What is the point of using a in-memory database if you want to dump i= t? >> > >> > It's just another data structure at that point, so why wouldn't I want >> > to be able to include it in my pdmp file? Why would I want to make my >> > internal data structure available as a separate file, or manage >> > creating and tracking those files? >> >> My bad, I did not understand that you were talking about dumping in >> terms of what temacs does. > Also for redumping with dump-emacs-portable. > >> [...] Perhaps you could be more clear if you have >> a specific example of what you think a in-memory database could be used >> for when dumped along with Emacs? > > * Anywhere a large association list or hash table is currently used > * Caching library locations, checksums, and modification times for > more efficient loading > * Tracking customization variables, dependencies, etc for generating > the correct sequence of initialization commands at startup > (particularly after redumping) Are we sure that a database is more efficient than a hash-table (which can already be printed and read)? Or are we talking about unusually extreme values, like in your other message where you were loading 2000+ packages? > I'm sure there's more, but we won't know until the programming idiom > is readily available and easy to use. Are there any other languages that support this kind of interaction, where we could learn some lessons about the advantages and limits of these ideas? > Lynn --=20 Philip Kaludercic