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

[Graham Fawcett]

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