[MLton] SQLite3 MLton binding

[Wesley W. Terpstra]

On Feb 9, 2007, at 2:17 PM, Vesa Karvonen wrote:
> Quoting "Wesley W. Terpstra" <terpstra at gkec.tu-darmstadt.de>:
> [...]
>
> Just a quick note (I don't have time right now to take a closer
> look at this).  Are you familiar with the following article?
>
>   Domain Specific Embedded Compilers
>   Daan Leijen, Erik Meijer
>   http://citeseer.ist.psu.edu/leijen99domain.html
>
> IOW, instead of ad hoc strings of SQL or parameterized SQL templates,
> introduce a (typed) combinator library to express queries.

I've read it now. I'm not particularly convinced. Though it's harsh,  
I think it is a lot of dubious work for the developer in order to  
make the library harder to use.

1. Despite their effort at making queries safe, the queries still  
aren't safe: table structure can be changed by another program after  
compilation. eg: "select * from table where x*y=$z" only works if x  
and y can be multiplied. If the schema for table changes x to a  
string, the binding doesn't do anything but give the user a false  
sense of security.
2. Returned columns are only superficially type-safe. The real output  
columns might have different types. The staticly compiled expression  
has no way of knowing the type of the columns output by the SQL  
engine to stop this error---it depends on the schema which the  
binding doesn't know.
3. They need to use an inelegant fetch method for each column. My  
library asks you the types, and gives you a convenient reader that  
converts a row at a time for you.
4. The user has to learn a new set of keywords/meta-language when he  
already knows SQL. Their binding also makes queries harder to read,  
despite being longer.
5. With such a meta-language you can't allow extensible query results  
or user-specified queries.
6. Even if they figured out how to make input and output columns type  
safe, the table can be altered and thus breaks any guarantees they  
thought they had.

In summary, it seems to me that the only benefit of their proposal is  
not having to write the string down. Instead, you use arcane, binding- 
specific keywords that eventually create the string you wanted. You  
already know SQL, so you knew what string you wanted, so you might as  
well have just written it down. Any safety the authors claim to have  
added is illusionary, due to the nature of SQL. I guess the compiler  
can catch typos in SQL keywords in the string, but so will even  
superficial testing. They can't detect logical mistakes due to schema  
abuse/changes, and those are exactly the bugs that are hard to track  
down.