[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-users] Request for comments on the SQLite3 egg API
From: |
Thomas Christian Chust |
Subject: |
Re: [Chicken-users] Request for comments on the SQLite3 egg API |
Date: |
Fri, 29 Jun 2007 10:03:19 +0200 |
User-agent: |
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.4) Gecko/20070509 SeaMonkey/1.1.2 |
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.