chicken-users
[Top][All Lists]
Advanced

[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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]