Re: db interface (was Re: Scheme is too complicated)

[Tel <telford@eng.uts.edu.au>]

> >   - This is a mapping from a functional to a declarative
> >     language.  This job is complicated and probably impossible.
> 
> I don't buy that one, since scheme can support declarative, object
> oriented and functional as well as a whole host of other styles of
> programming.

I agree here, the fundamental idea of making a program by writing
lists of symbols could be considered declarative. Also, people have
been sneaking functional bits into SQL since as long as I can remember.
Point of view means so much in these discussions.

> >   - Someone must write it.
> 
> Someone has to write everything...
> 
> >   - Everybody must learn it.
> 
> They have to learn something anyhow, and this is hardly an excuse.

On these two points I disagree. If you want to support major league,
high profile relational databases, direct support SQL is the easiest
way to go. The author of the database has done most of the work by building
the SQL parser in the first place so there is less work for the scheme
interface author and SQL textbooks, courses, experts, example code are
all plentiful so the learning/documentation is kept minimal.

> >   - It makes it probably impossible to use some DB special features.
> 
> There is no reason why the only way to generate sql for the interface
> has to be thru this nice schemified manner.

Yup, at the end of the day you need a direct interface anyhow so why
not do that at the start of the day and worry about flying solo round
the world AFTER we put some wings and a tail on?

I appreciate the advantages noted but SQL itself isn't so ugly as to
not have many of the stated advantages anyhow, especially being commonly
used (with variations tis true).

I suggest a thin layer interface that just takes a list or tree of
scheme strings, symbols and numbers and scans it all in left-to-right,
depth-first ordering (same as (display) would do) formatting the resulting
sequence of items into whatever is necessary for the SQL engine, and
sending off the query.

This allows you to rattle off a quick one liner like:

(db-make-dynaset "SELECT * FROM MYTAB;")

or to slip in a quasi-quote:

(define x "MYTAB")
(db-make-dynaset `(SELECT * FROM ,x ";"))

transparent handling of numbers is pretty important, nothing
is more irritating that always fiddling with changing numbers to
strings.

(define y 23)
(db-make-dynaset `(SELECT * FROM ,x WHERE age > ,y ";"))

since SQL isn't too fussed about spaces in most areas you could
blindly stick spaces between symbols in a list, a few extra spaces
won't hurt. OK, I'll admit that it isn't an elegant solution
but anyone with a smattering of SQL and scheme should be able to
figure out what is going on, it requires very few smarts from the
interface but still allows a lot of scheme's nicities when putting
together queries. I guess there will be a problem distinguishing SQL
parenthesis from those of scheme but a blanket rule like always
use "(" and ")" for SQL should do the job.

	- Tel