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

[Thomas Christian Chust]

Ivan Shmakov wrote:

> Thomas Christian Chust <address@hidden> writes:
>
>> [...]
>> adding a few functions and macros to implement ternary logic
>> sounds good to me.
> 
>        ... And these should be in a separate library, so that they
>        could be used along with any SQL engine.

Hello,

if those things were put into a separate library along with a NULL
singleton, the SQLite3 egg could be modified to use this NULL value if
that separate library was loaded and to use #f otherwise -- that would
also keep backwards compatibility and reduce the amount of code to type
in order to get one's preferred behaviour even more.

>> But the idea to use (void) to represent NULL still appeals to me
>> because of their similar meaning
> 
>        I feel that the semantics of an ``unspecified value'' is, well,
>        underspecified.  Is it guaranteed, e. g., that (eq? (void)
>        (void)) will always be true?  (So that (sql-null? o) function
>        could be implemented.)

As far as CHICKEN is concerned, (void) returns a special atomic object
that is represented directly as a machine word and (eq? (void) (void))
is always true.

>> and because no additional memory and garbage collection time would be
>> wasted for another useless singleton class instance ;-)
> 
>        Won't it complicate debugging?

I don't think so, but that may be a matter of taste.

>> 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.
> 
>        It could be the solution.
> 
>        However, my opinion is that the support for representing SQL
>        NULL with #f (or any other arbitrary value) is not quite a good
>        thing and, eventually, should be dropped.  Since I view it,
>        thus, as a temporary solution, I'd recommend a special SQL NULL
>        value be used as the default value for the parameter, still
>        allowing the old code to invoke ``compatibility mode'' with
>        `parameterize'.
> [...]

Well, my opinion is, that there may be more than one opinion on this
topic -- the more different behaviours can be supported by a library
without additional effort, the better, as everyone will be happy that he
isn't forced to use a specific programming style and can rather stick
with his preferred style ;-)

I for one would stick with the #f returning behaviour. I come from a C
and Assembler background and I love the typeless NULL pointer which also
means false. If I were to implement my own Scheme variant, I would
return #f for end of file conditions and would make it identical with
'() and the undefined value as well. I simply think this is very
convenient and it saves a bunch of predicate function calls replacing
them with simple flag tests performed by the processor. But I also think
that such stylistic questions are a matter of taste and that it's pretty
useless to debate about them.

>> 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))
> 
>        Unfortunately, this won't work with the (sql-null) definition
>        I've suggested.

This would work with any setting for the parameter, I think.
Unfortunately TinyCLOS doesn't support predicate specializers to make a
cleaner method definition possible, but that's merely a stylistic point.

> [...]
>> 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.
> 
>        ... Provided that there's not a line of code, not in program,
>        nor in a library used, which assumes #f is a SQL NULL.
> [...]

If you write your code from scratch and set the parameter to use a
singleton NULL value, then I guess one can assume that you wont at the
same time rely on #f returns?!?

If, on the other hand, you don't do anything special, compatibility mode
would be active and old code should continue to work.

Problems should only arise if old and new code with different styles
were be mixed, but here parameterize would help.


cu,
Thomas