unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Tomas Hlavaty <tom@logand.com>
To: Philip Kaludercic <philipk@posteo.net>
Cc: Lynn Winebarger <owinebar@gmail.com>, emacs-devel@gnu.org
Subject: Re: [NonGNU ELPA] New package: sqlite3
Date: Tue, 21 Mar 2023 23:46:30 +0100	[thread overview]
Message-ID: <87v8itbu49.fsf@logand.com> (raw)
In-Reply-To: <875yatn70c.fsf@posteo.net>

On Tue 21 Mar 2023 at 21:12, Philip Kaludercic <philipk@posteo.net> 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.

> Tomas Hlavaty <tom@logand.com> writes:
>> On Tue 21 Mar 2023 at 16:53, Philip Kaludercic <philipk@posteo.net> 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.



  parent reply	other threads:[~2023-03-21 22:46 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-04 10:17 [NonGNU ELPA] New package: sqlite3 Jonas Bernoulli
2023-03-04 11:39 ` Philip Kaludercic
2023-03-06 18:43   ` Jonas Bernoulli
2023-03-14 16:16     ` Philip Kaludercic
2023-03-14 22:46       ` Jonas Bernoulli
2023-03-15  8:05         ` Philip Kaludercic
2023-03-21  6:51       ` Jean Louis
2023-03-21 10:55         ` Lynn Winebarger
2023-03-21 11:08           ` Philip Kaludercic
2023-03-21 11:56             ` Lynn Winebarger
2023-03-21 12:18               ` Philip Kaludercic
2023-03-21 13:04                 ` Lynn Winebarger
2023-03-21 16:53                   ` Philip Kaludercic
2023-03-21 21:00                     ` Tomas Hlavaty
2023-04-07  4:53                       ` Jean Louis
2023-03-21 23:58                     ` Lynn Winebarger
2023-03-22  8:10                       ` Philip Kaludercic
2023-03-22 15:05                         ` Lynn Winebarger
2023-03-23  0:07                           ` Lynn Winebarger
2023-03-21 20:42             ` Tomas Hlavaty
     [not found]               ` <875yatn70c.fsf@posteo.net>
2023-03-21 22:46                 ` Tomas Hlavaty [this message]
2023-03-22  8:00                   ` Philip Kaludercic
2023-03-21 20:36         ` Tomas Hlavaty
2023-04-07  5:17           ` Jean Louis
2023-03-06  5:08 ` Richard Stallman
2023-03-14 14:36   ` Jonas Bernoulli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87v8itbu49.fsf@logand.com \
    --to=tom@logand.com \
    --cc=emacs-devel@gnu.org \
    --cc=owinebar@gmail.com \
    --cc=philipk@posteo.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).