Do you mean #("string") or #(string)? I think either works, strictly speaking, but the former is much clearer in intent, and results in a simple dispatch rule: is the contents a list (and only a list), a string (and only a string), or neither?
Yes, the former. Strings are much more familiar than vertical-barred symbols. I have added a note about vertical bars.
BTW, the "(create-table-if-not-exists items..." example looks like it has way too many closing parens.
Fixed.
Hmmm, sorry to say, but looking really really closely at that CREATE TABLE example, I think it fails the goal of "without knowing much about SQL",
I meant that the *code* doesn't have to know any SQL (except its lexical syntax). The user still does, as well as the construction rules, which is admittedly an extra burden. However, I don't think it's impossible to reverse the transformation either with just a lexer, though I haven't designed it for that purpose. The hardest part of a reverse algorithm would be the ultimate escapes, which could be set off in the SQL with /**/ before and after each one: what do you think of that? Remember that the SQL is not really meant for human eyes, especially because of the excess parens in expressions.
Arrgh, wrapping the arguments to a UNION or similar operator in parens is bad syntax, at least in SQLite. I'll remove that example.
although there's value to moving from the domain of strings to S-expressions.
Yes, primarily access to quasiquotation, which is far superior to parameters (it can, for example, parameterize the name of a table), but also automated construction in the style of various SQL-making packages. Those, however, try to enforce the exact syntax, and fail because different implementations have different syntax.