[Top][All Lists]

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

Re: Adding emacsql to NonGNU ELPA?

From: Tomas Hlavaty
Subject: Re: Adding emacsql to NonGNU ELPA?
Date: Fri, 28 Jan 2022 20:12:37 +0100

On Fri 28 Jan 2022 at 02:22, Tim Landscheidt <tim@tim-landscheidt.de> wrote:

> Tomas Hlavaty <tom@logand.com> wrote:
>>> There isn't anything similar for other languages, so why for
>>> SQL?
>> Of course there is.  Lisp is full of stuff like this.  For example,
>> there is a cons tree language for regular expressions in Emacs:
>>    (info "(elisp) Rx Notation")
>> There are also cons tree bases representations of xml, html, svg etc.
>> One can conveniently represent almost anything using cons trees.
>> It is great.
>> In Lisp, the first thing to do is to escape the concat string
>> inconvenient and insecure hell and use cons tree based representation
>> which is very easy to work with.
>> […]
> These work for those languages because they have very few
> base elements, much like Lisp; one can probably fit the EBNF
> for XML on a single page, and the transformation will be
> reasonably predictable.
> SQL on the other hand almost has a different syntax for ev-
> ery command.  So one would either have to have different
> etc., or come up with a generalized version where the pro-
> grammer would probably have to test each time if the SQL ge-
> nerator generated the SQL that the programmer was expecting.
> I find it much more straightforward in that case to write
> down the SQL code itself, and use (ideally placeholders à la
> DBI or) sql-quote-string to only transform what needs to be
> transformed from Emacs Lisp to SQL.

We are talking about cons tree based "meta-syntax".
Similar to how Lisp programs are written using cons tree based
symbolic expression "meta-syntax".
For such "meta-syntax", it is trivial to have a rule for example,
that :create-index is output as CREATE INDEX or
:create-unique-index is output as CREATE UNIQUE INDEX etc.

In addition, you want the syntax to be validated.
That is a different issue.
It can be built on top of the cons tree based "meta-syntax".
In this case there is no simple way to validate arbitrary
SQL upfront except encoding the complex SQL rules explicitly
somehow.  And do it for each SQL dialect.
Cons tree based "meta-syntax" does not solve validation
in itself, but helps here significatly,
because one can use backquote and comma to build the tree
programatically and validate the structure in a recursive function.
This is much more convenient than concatenating strings.
Moreover, it is possible to make it extendable,
similar to what Lisp does with macros.

It is similar to what Lisp does.  Write symbolic expressions
and the interpreter/compiler does the validation/transformation.
Write a function which takes cons tree and outputs what you want.
The more validation you want, the more complex such function will be.

reply via email to

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