Thomas Christian Chust <[EMAIL PROTECTED]> 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. _______________________________________________ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users