[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: |
Ivan Shmakov |
Subject: |
Re: [Chicken-users] Request for comments on the SQLite3 egg API |
Date: |
Wed, 4 Jul 2007 00:42:18 +0700 |
Thomas Christian Chust <address@hidden> writes:
>>> adding a few functions and macros to implement ternary logic sounds
>>> good to me.
[...]
> Hello,
> if those things were put into a separate library along with a NULL
> singleton, the SQLite3 egg could be modified to use this NULL value
> if that separate library was loaded and to use #f otherwise
I'm curious, how do you check whether the library is loaded in
Chicken or not?
[...]
>>> Another idea that just came to my mind is the following: One could
>>> add a parameter sqlite3:null-value to the SQLite3 egg, which
>>> defaults (for backwards compatibility reasons) to #f and defines
>>> the value returned from SQLite3 functions to represent NULL.
>> It could be the solution.
>> However, my opinion is that the support for representing SQL NULL
>> with #f (or any other arbitrary value) is not quite a good thing
>> and, eventually, should be dropped. Since I view it, thus, as a
>> temporary solution, I'd recommend a special SQL NULL value be used
>> as the default value for the parameter, still allowing the old code
>> to invoke ``compatibility mode'' with `parameterize'. [...]
> Well, my opinion is, that there may be more than one opinion on
> this topic -- the more different behaviours can be supported by a
> library without additional effort, the better, as everyone will be
> happy that he isn't forced to use a specific programming style and
> can rather stick with his preferred style ;-)
... However, the ``parameter'' approach you've suggested seems
not to solve this, more general, problem. I'll comment on this
point separately (if that would be necessary.)
> I for one would stick with the #f returning behaviour. I come from a
> C and Assembler background and I love the typeless NULL pointer which
> also means false.
Well, I program C since 1995 or so (started to study x86
assembler about the same time.) In my programs, I tend to
distinguish NULL (or 0) from false. E. g., I'd write:
if (a == 0) { ... }
if (a != 0) { ... }
rather than:
if (! a) { ... }
if (a) { ... }
Except when `a' is expected to contain a boolean value.
Likewise with pointers:
if (MALLOC_VAR (a) == 0) {
... free everything...
return 0;
}
> If I were to implement my own Scheme variant, I would return #f for
> end of file conditions and would make it identical with '() and the
> undefined value as well.
This has an additional advantage of having the reader to stop on
a ()-form in the source, hasn't it?
[...]
>>> I suppose that this is the most flexible solution suggested so far:
>>> If you want nearly the same behaviour as now, no action is
>>> required. If you want a NULL singleton, add the line
>>> (sqlite3:null-value (void)) or (sqlite3:null-value (make
>>> <sqlite3:null>)) to the top of your program and you're done.
>> ... Provided that there's not a line of code, not in program, nor in
>> a library used, which assumes #f is a SQL NULL. [...]
> If you write your code from scratch and set the parameter to use a
> singleton NULL value, then I guess one can assume that you wont at
> the same time rely on #f returns?!?
Yes, I won't. But the library author may.
> If, on the other hand, you don't do anything special, compatibility
> mode would be active and old code should continue to work.
> Problems should only arise if old and new code with different styles
> were be mixed, but here parameterize would help.
Not in all the cases.
- Re: [Chicken-users] Request for comments on the SQLite3 egg API, Ivan Shmakov, 2007/07/02
- Re: [Chicken-users] Request for comments on the SQLite3 egg API, Thomas Christian Chust, 2007/07/02
- Re: [Chicken-users] Request for comments on the SQLite3 egg API, Ivan Shmakov, 2007/07/03
- Re: [Chicken-users] Request for comments on the SQLite3 egg API, John Cowan, 2007/07/03
- Re: [Chicken-users] Request for comments on the SQLite3 egg API, Thomas Christian Chust, 2007/07/03
- Re: [Chicken-users] Request for comments on the SQLite3 egg API,
Ivan Shmakov <=
- Re: [Chicken-users] Request for comments on the SQLite3 egg API, Peter Keller, 2007/07/03
- Re: [Chicken-users] Request for comments on the SQLite3 egg API, Thomas Christian Chust, 2007/07/04
- Re: [Chicken-users] Request for comments on the SQLite3 egg API, Ivan Shmakov, 2007/07/06
- Re: [Chicken-users] Request for comments on the SQLite3 egg API, Thomas Christian Chust, 2007/07/06
- Re: [Chicken-users] Request for comments on the SQLite3 egg API, John Cowan, 2007/07/06