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

[Ivan Shmakov]

> > > > > Thomas Christian Chust <address@hidden> 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.