Re: [Chicken-users] Request for comments on the SQLite3 egg API

[Thomas Christian Chust]

Ivan Shmakov wrote:
>>>>>> John Cowan <address@hidden> writes:
> 
>>> 1. Introduce a new separate singleton type for SQL NULL values and
>>> refrain from using booleans altogether, because there is no SQL
>>> boolean type in SQLite3.
> 
>> I favor a variant of this: introduce a singleton type for SQL NULL
>> values, and map #t and #f inbound to 1 and 0 respectively (but not
>> outbound, of course).  Ideally, the singleton type would be the same
>> in all SQL eggs rather than SQLite-specific: one could use the symbol
>> sql:null or even the empty list, which some people already pronounce
>> "nil".
> 
>        I'd rather like it be a type disjoint from all the other Scheme
>        types.
> 
>        May we have a library to implement SQL-like ternary logic as
>        well?  E. g.:
> [...]

Hello,

adding a few functions and macros to implement ternary logic sounds good
to me.

But the idea to use (void) to represent NULL still appeals to me because
of their similar meaning and because no additional memory and garbage
collection time would be wasted for another useless singleton class
instance ;-)

Another idea that just came to my mind is the following: One could add a
parameter sqlite3:null-value to the SQLite3 egg, which defaults (for
backwards compatibility reasons) to #f and defines the value returned
from SQLite3 functions to represent NULL. A specialization for the third
parameter of sqlite3:bind! on the class <top> would be added which would
check whether (eq? v (sqlite3:null-value)) and execute the two parameter
variant of sqlite3:bind! in that case, or generate an error in any other
case. Additionally one could offer a singleton class <sqlite3:null> and
some ternary logic support for convenience.

I suppose that this is the most flexible solution suggested so far: If
you want nearly the same behaviour as now, no action is required. If you
want a NULL singleton, add the line (sqlite3:null-value (void)) or
(sqlite3:null-value (make <sqlite3:null>)) to the top of your program
and you're done. You can still add whatever specialization you want to
sqlite3:bind! for booleans. And whatever value you choose to represent
NULL, unless you add some specializer conflicting with your choice to
sqlite3:bind!, you are guaranteed that the NULL value can be passed both
in and out of SQLite3.

How do you like this approach?

cu,
Thomas