Thomas Christian Chust <[EMAIL PROTECTED]> writes:
>> I'm curious, how do you check whether the library is loaded in >> Chicken or not? > Hello, > CHICKEN maintains a list of active extensions: > http://chicken.wiki.br/Unit%20library#feature? IIUC, it requires an explicit `register-feature!' from a library? >> [...] ... 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 don't see any serious problems resulting from that approach. Maybe > I'm just thinking in the wrong direction. It would be nice if you > could point me in the right one. It's not that this approach will result in any problems. My concern is that it, when applied to solving either ``freedom of choice for the representation of NULLs'' or ``saving programmer of extra keystokes'' problems, actually, seem to give rather bad results. My opinion is that the approach seem to complicate writing of library functions. E. g., with NULLs represented with #f, one writes: (define (foo ...) (cond ((query...) => handler...) ...)) With a `sql-null' object for NULLs one would write: (define (not-sql-null? o) (not (sql-null? o))) (define (foo ...) (cond ((query...) sql-not-null? => handler...) ...)) And `parameterize' doesn't seems to help much, since it thus requires one to write (if one keeps in mind that he's own library function might be called from a program or a library with a different NULL): (define (foo ...) (parameterize ((the-null #f)) (cond ((query...) => handler...) ...))) While it could save a few keystrokes with particularly large functions, containing a lot of queries, it doesn't seems to do any good for small ones. When one's to use closures, the things are getting even worse: (define (bar ...) (parameterize ((the-null #f)) (cond ((query...) => (lambda (result) (lambda (argument-1 ...) (parameterize ((the-null #f)) more-queries...)))) ...))) ... And when the function takes a function argument: ;; in the library (define (baz proc ...) (parameterize ((the-null #f)) ...)) ;; in the main program (baz (lambda (argument-1 ...) (parameterize ((the-null my-null)) queries...)) ...) Furthermore, one should never try to return the SQL NULL value returned by the function called to the calling function, e. g. the following is disallowed: (define (qux ...) (parameterize ((the-null my-null)) (cond ((query...) my-null? => identity) ...))) Since the NULLs of the function and of its caller may differ. One more point is that the inconsistences like such are likely to limit the composition in general, which is an important feature of the Scheme language as a whole. I believe that the freedom of composition is the very feature that will save the programmer of unnecessary work. Of course, no `parameterize' will be necessary if all of the functions used rely on the same representation for NULL. This is why I ask for the ``parameter'' approach to be used only temporarily, to get around the compatibility issues. _______________________________________________ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users