Re: [NonGNU ELPA] New package: sqlite3

[Lynn Winebarger]

On Tue, Mar 21, 2023 at 8:18 AM Philip Kaludercic <philipk@posteo.net> wrote:
> Lynn Winebarger <owinebar@gmail.com> writes:
>
> >> > * Treating code as data and vice-versa is a powerful programming 
> >> > technique
> >>
> >> 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.

>
> >> To me the
> >> advantage of something like `rx' is that I can insert comments and make
> >> 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 data
> >> > 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 it?
> >
> > 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)

I'm sure there's more, but we won't know until the programming idiom
is readily available and easy to use.

Lynn