This is the mail archive of the guile@cygnus.com mailing list for the guile project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
> > - 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