On Fri, Feb 29, 2008 at 2:57 PM, Tobia Conforto <address@hidden> wrote:
So, to recap:
Perfect recap! :-)
(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.
True. I suspect there will be slightly more overhead here than with
using an immediate, perhaps noticeably on large queries. Ideally
(sql-null) would be a closure that constantly returned the same
instance, while (sql-null?) was just a record predicate, as in your
example.
I *believe* that if multiple modules include (define-record sql-null
...), that the predicates will work across definitions. E.g. if your
module defines a sql-null record, and mine does too, then instances of
your type will satisfy my predicate, as long as the type-names match.
This is *ugly*, but it would be better than forcing each db egg to
dynamically link to some "sql-null egg".
This is not a terrible answer for the sql API, though perhaps more
terrible for other APIs, and I don't think it would be bad to solve
both problems at once (the sql-null, and the well-intentioned 'abuse'
of (void) in current eggs).
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.
My preference by far, too.
Thanks for this summary, Tobia,
Graham
_______________________________________________
Chicken-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/chicken-users