Re: [Chicken-users] New immediate values (was: DBI)

[Tobia Conforto]

So, to recap:

        '(), 0, "", #f, 'null, (gensym)

Very bad for representing SQL NULL, because some DBs or DB operations  
could theoretically support lists, numbers (doh), strings (doh),  
booleans, and symbols, and in those cases we wouldn't want the null  
value to clash with valid values.

For example I'd quite like to see a Postgres extension (or just the  
Chicken interface) supporting symbols in an efficient manner, with a  
symbol table and all.  As it can't be ruled out, having symbol? return  
#t for sql NULL is a very bad idea.

        (void)

Bad.  You would need to test for it by (eq? x (void)), which is  
terrible, and is a non-value inappropriate for representing an actual  
return value, as already expressed in this thread.

        (define-record-type sql-null (sql-null) sql-null?)

Not too bad.  Any piece of code could create null values with (sql- 
null), even in different compilation units.  People would just have to  
remember to use (sql-null? x) instead of eq?.  The API could state  
that eq? on two sql-null values is undefined.

        A new immediate value

IMHO the best option, and it could be useful for other APIs too, but  
if Felix says no he's probably right.


Tobia