>> Putting {} in the symbol names does look like deliberately shooting oneself
>> in the foot :)
>
> Sure, but I'm not sure the API needs to take too much effort to prevent
> people from doing it.

That's what I meant to say: it's not a big deal either way :)

>>>       (query "SELECT $2, $3" 1 2 3)
>>>
>>> It won't give an error about $1 not being used
>
> Yeah, that's a bit awkward but it's no different from a procedure in a
> programming language not using one of its positional arguments.

It's a bit different in that the query and the parameters are given by
the same party, whereas a procedure and its caller can be completely
different. Arguably SQL queries can also be treated as library code and
re-used, but that's risky without some higher-level wrapper to protect
against accidental misuse.

> You could use a sort of taint mechanism where you must wrap the SQL
> strings in an object to ensure that it's been safely processed.  But I
> also think that makes the common case annoying to use.

That may be a good safeguard. It's hard to say without an idea of the
specifics.

> The current API shouldn't try to do too much, IMO; we're just looking
> for an abstraction over database drivers and abstracting away the surface
> differences.  I mean, in the Scheme base language itself we also don't
> have a pathname abstraction for the file operations, even though
> programmatically composing pathnames is tricky business and tends to
> be done a *lot*.

You're right. In the case of pathnames, they are simple enough that the
heavy abstractions tend to cause constant pain with hardly any benefit.
I hope the same isn't true for SQL DSLs ;-)

Seriously though, I've used Roda in Ruby and it's a godsend. You can
have a procedure that returns only a select clause, then other
procedures that add different where clauses to it and stuff like that.
It's all "purely functional" so you can easily build up a pattern
language of queries for your app.

> I'd say providing a safer way to write SQL is the job of a higher level
> library.

I agree. But I'd also claim that the combined set of all Scheme APIs
should look like a big arrow pointing most people to the safer APIs :)
So it's not a big deal if the low-level APIs look a bit ugly.

Would you like to start drafting a higher-level DSL right away? It can
be done concurrently with the low-level spec, and it will probably
improve both specs if they have to take each other into account from the
start...

A DSL is a big undertaking that can be taken in many directions. We
could start with something informal like a wiki and just try lots of
different approaches rapidly.