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

[Thomas Christian Chust]

Ivan Shmakov wrote:
>>>>>> 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?

Hello Ivan,

interestingly I somehow had the information stored in my head that this
should work for both statically and dynamically linked extensions, but
you're right, it only works by default for statically linked ones,
which, by default, do call register-feature!

In that case one will have to use the following generally useful procedure:

  (define (loaded? name)
    (or (feature? name)
        (memq name (map string->symbol ##sys#loaded-extensions))))

>>> [...]  ... 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:
> [...]

Ok, I get your point. While all the problems you mention can be
circumvented, it may indeed be pretty impractical to write new library
code that will work the same both with the API using #f and the ones
using a null singleton. It is also likely that one will obtain
unexpected results from old library code using SQLite3 only internally
where one could easily forget to use a parameterize form.

Yet, I'm not really suggesting that one should only write code that
works with any value of the sqlite3:null parameter. But with any other
approach than the parameterization one it is outright impossible to
combine old and new code.

I'm just not sure whether I should break the API right now or whether I
should allow a smooth transition.


cu,
Thomas