Re: sqlite3

[Qiantan Hong]

> We don't really require much of anything, it's just that Emacs doesn't
> work very well without some things.  Like gnutls.  This would be in the
> same category, so I'd expect 99.7% of Emacsen would have support for it
> toot sweet.
Implementing cryptography and TLS in Emacs Lisp is too much,
and would probably be hopelessly slow because they need to run
through every byte from the network traffic. There’s no other choice
than relying on either external gnutls-cli or gnutls as a library.

For sqlite3, my point is, in summary
1. As a query language, LISt Processing works equally well,
    and even if lisp starts to not work well, Prolog works better than SQL.
    There’s also the question of introducing two scripting languages into Emacs.
2. As a persistent kv store, it’s massive overkill.
    I postulate that a plain Emacs Lisp log-structured implementation is 
suffice.

IDK if I read the context correctly, but is it that your main intention 
currently
is to have a persistent kv store?
If that’s the case I might try to find sometime to hack a Emacs Lisp 
implementation.

In fact I can probably do better if I implement a real object/Lisp data store
rather than kv-store — aka, you define a root object of the object store,
and every time Emacs loads up the object graph reachable from the root
object is faithfully reconstructed.
Sounds much sweeter than SQL CRUD!

> (Except for those that hate SQL sooooo much that they can't even stand
> the thought of something in Emacs talking SQL even if they can't see
> it.)
There’s hardly anything in Emacs that can’t be seen, until maybe you reach
Intel microcodes, and electrons ;)
Either Lisp or Prolog would probably be more friendly for Lisp hackers,
comparing to SQL strings (flashbacks from being an SQL injection hacker…)


Best,
Qiantan