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
_______________________________________________
Chicken-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/chicken-users