[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [NonGNU ELPA] New package: sqlite3

From: Lynn Winebarger
Subject: Re: [NonGNU ELPA] New package: sqlite3
Date: Wed, 22 Mar 2023 11:05:20 -0400

On Wed, Mar 22, 2023, 4:10 AM Philip Kaludercic <philipk@posteo.net> wrote:
Lynn Winebarger <owinebar@gmail.com> writes:

> On Tue, Mar 21, 2023 at 12:53 PM 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?
> Not at all.  I don't think I can communicate via email the power of
> generative programming techniques, and why basing them on simple
> string concatenation is a bad idea, so I'm going to stop trying.

I get that, and I am not advocating for string concatenation.  Perhaps
that is what is confusing me?

> I don't think "? ? table values ( 1.0, 'Foo' )" can be supplied with
> 'insert and 'into as parameters.

Nor do I, but I doubt the necessity.  SQL is a very brittle language,
and replacing one keyword with another will usually require other
changes to be made as well.

Exactly the point of a DSL that compiles to a query.

Whether emacsql is the best DSL or not, I don't know.  I really haven't used it.  It has the distinct advantage of existing and providing a syntax tree of the query, which are strong points.

>> 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?
> Who determines what is extreme? 

Experience and convention?  There is no algorithm to determine this, but
before 2000 the highest number of Emacs packages I heard someone was
using was maybe 300-400 (which I also think is an absurd number).

I don't know why it's absurd.  There are ~300 packages in gnu elpa, ~200 in nongnu elpa, and over 5000 in melpa.
The vast majority are single files.  

My experiments have shown that a substantial part of the pain of adding packages is simply due to the cost of extending the load path.  I really question how much of the effort in these configuration management systems and specialized configs like doomemacs is prompted by the inordinate cost of the extending the load path just to add a one-file package.

I can report from experience that most packages can be simultaneously loaded and work fine as long as conflicting modes are not simultaneously in effect.   

>                                  Tasks that aren't done today because
> they are difficult to code efficiently?  Tasks that seem extreme when
> you write the code in direct style may become much less extreme once a
> well-crafted table/query facility is available.  I don't think simply
> *installing* 2000+ packages is all that extreme in itself.  Even
> loading all those packages, particularly when using redumping, is not
> particularly extreme in terms of resource consumption on modern
> desktop hardware.
> Hash tables only index a single key of a data set.  And they don't
> address tasks like efficiently joining tables.
> My personal interests run to using relational programming for problems
> like abstract interpretation and compiler implementation. 

In Elisp?

Eventually, sure - for elisp itself, anyway.    It's a longer term project for me, though.  

> You might consider the LINQ sublanguage of C# and other .NET-based
> languages as an example of a useful query DSL.

As far as I understand (I have no experience with .NET-based languages),
this is only syntax sugar? 

"Syntactic sugar" should be reserved for syntax that the compiler immediately transforms into a simpler syntactic structure.  Otherwise any DSL can be shrugged off as syntactic sugar.  I don't know the implementation details, but it's an example of a query DSL integrated into an otherwise imperative/OO paradigm language.

Or how does this relate to the point of
dumping an in-memory database.

I just think it's a powerful paradigm that will eventually be utilized in core tasks involved in managing emacs itself, like reasoning about customization variables and relationships between them.  Things that aren't done now because doing them without a relational language to take care of the details is painful as error prone.
Once those kinds of tables are in use at startup, why wouldn't you want to include them in pdmp file?  Particularly if you record pointers to objects as integers in the database - the dumper/loader will be needed to ensure those remain consistent.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]