John Cowan wrote: > Thomas Christian Chust scripsit: > >> 1. Introduce a new separate singleton type for SQL NULL values and >> refrain from using booleans altogether, because there is no SQL >> boolean type in SQLite3. > > I favor a variant of this: introduce a singleton type for SQL NULL > values, and map #t and #f inbound to 1 and 0 respectively (but not > outbound, of course). Ideally, the singleton type would be the same > in all SQL eggs rather than SQLite-specific: one could use the symbol > sql:null or even the empty list, which some people already pronounce > "nil".
Hello John, as some database engines have an SQL list type, some Schemes make no difference between #f and () and one of the main reasons for this change would be compatibility, I don't think the empty list would be a good choice for the object representing NULL. Maybe one could use the return value of (void), which really has a very similar meaning in Scheme as NULL has in SQL -- with the notable exception that Scheme has no ternary logic like most SQL engines. >> 2. Keep the data extraction routines returning #f to represent NULL >> but add an arbitrary default specialization of sqlite3:bind! on >> booleans that represents #f as NULL and #t as 1. > > This has absolutely no virtues in my mind except backward compatibility. > It's extremely unnatural. I agree, but backward compatibility may be a big issue. cu, Thomas -- Murphy's Law is recursive. Washing your car to make it rain doesn't work. _______________________________________________ Chicken-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/chicken-users
