Re: sqlite3

[Alexandre Garreau]

Le lundo, 6-a de decembro 2021, 14-a horo kaj 8:48 CET Stefan Kangas a 
écrit :
> Qiantan Hong <qhong@mit.edu> writes:
> 
> 
> 
> > I really don’t like the idea of introducing an external UNIX-y
> > dependency that significantly overlaps with Emacs Lisp itself,
> > it’s almost like saying “let’s make Emacs programmable using
> > JavaScript, because JavaScript is faster, safer, etc etc”.
> 
> I don't see any similarity between Lars' suggestion and the idea of
> introducing a new language to rival Emacs Lisp.

SQL is a full-fleged logical language akin to prolog: the comparison is 
very sound.  Because then will arrive the same tradeoff occurs than in most 
modern webapps: whenever you interface with persistent I/O you start 
thinking “should that algorithm/datastructure be coded in SQL or <native 
language>?”, and the right answer is almost always SQL because that will 
give more freedom to planning, reorganization, optimization, etc.

the situation would be different if there was a powerful and efficient and 
free implementation of sql in lisp (postgres at the beginning almost 
became one but early changed direction toward C, which is more understood 
and causes less disagreement).

> > We don’t need the sql language. In most cases it’s no better than
> > MAPCAR-ing and FILTER-ing, and it’s strictly no better than just
> > embedding a Prolog interpreter in Emacs Lisp.
> 
> AFAIU, the idea is to hide away any SQL inside a new sqlite.el that will
> provide some ORM.  I don't see this as fundamentally different to
> depending on gdbm, or indeed any other store, which presumably also
> would not be programmable directly in Emacs Lisp.

gdbm could be a fully compatible backend for the exact same usage and 
interface as sqlite.  but that would mean purposedly limiting the power 
and expressiveness provided by sqlite.  people would want to circumvent 
that.