Re: [Chicken-users] Request for comments on the SQLite3 egg API

[Ivan Shmakov]

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