On Fri, Feb 29, 2008 at 2:57 PM, Tobia Conforto <[EMAIL PROTECTED]> 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 Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users