At the command line interface (CLI) in SQLite (and most SQL implementations) is an interpreted set at a time language with implicit loops.
Efficient low level languages (such as C) process data a record at a time and the existing API is appropriate for them. Object Oriented Interactive Languages (OOIL ?) can receive a Table, a View or a Query all at once as a data set. I would count among the OOIL languages: R, Python, Julia Scala, MatLab/Octave and APL. In a slightly different category would be Java and C# which are object oriented and arguably interpreted, but are not intended to be used interactively at a command line with a Read-Evaluate-Print-Loop (REPL). The intent of the higher level API is to improve the reliability of the interfaces. The existing SQLite APIs are correct, but hard to use in the sense that creating an interface from an OOIL language is more involved than just "wrapping" one by one a set of functions. What I am proposing is a second set of APIs that when trivially wrapped for use in an OOIL language would result in a function that makes sense to an OOIL programmer and interprets the SQL statements in a manner consistent with the SQLite CLI (perhaps it could even borrow code from the CLI). I believe R has remarkably good interface packages for SQLite, but that is not necessarily the norm across the other OOIL languages. I am assuming that the higher level API would be hard to use in C because its up to the programmer to write the low level code while maintaining a complex abstraction in their head (because C is better suited for creating abstractions than using them). Header files (.h) would help some but they would inflate the size of the code and still be hard for the C programmer to keep track of. So, that's why I see the need for a second higher API that might be written in C, but would certainly not be used in C! I am undecided as to whether the higher level API would be useful in Java or C#. Java and C# programmers might not be used to implicit loops and find them not worth the trouble; whereas R, Python or Julia programer would expect to get an entire table, view or query all at once. The higher level API would have to be optional, since it would not be desirable for a programmer or organization that needs SQLite to run with the smallest possible footprint on a phone, tablet or Internet of things (IOT) device. Just a wishlist idea. No rush for me because I am happy in R and will probably be moving from SQLite to client server SQL database before I move from R to Python, Julia or Java. Jim Callahan Orlando, FL <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> This email has been sent from a virus-free computer protected by Avast. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
