Re: SRFI-13 again [was: Re: string vs list processing]

[Martin Grabmueller]

> From: Marius Vollmer <address@hidden>
> Date: 25 Apr 2001 02:46:50 +0200
> 
> Martin Grabmueller <address@hidden> writes:
> 
> > I think I'll just merge my two shared libraries into one (called
> > libguile-srfi-srfi-13-14.so or something) , and let it get loaded by
> > both the (srfi srfi-13) and (srfi srfi-14) Scheme modules.
> 
> You could initlize the library like this in srfi-13.scm
> 
>   (dynamic-call "scm_init_srfi_13" (dynamic-link "libguile-srfi-srfi-13-14"))
> 
> and like this in srfi-14.scm
> 
>   (dynamic-call "scm_init_srfi_14" (dynamic-link "libguile-srfi-srfi-13-14"))
> 
> You don't need scm_init_srfi_13_14.

The problem is that some of the SRFI-13 procedures use a smob type
defined in srfi-14.c, so at least this must be initialized anyway.  so
I thought the cleanest thing was to just put them together.

The way I implemented it, the C primitives of SRFI-13 always get
loaded when SRFI-14 is used, and vice versa.  This is done behind the
user's back and the bindings of the module *not* imported are not
visible until it is imported explicitly.  The drawback is that the
loaded library is a bit bigger, but honestly, I can hardly think of
users who import SRF-14, but do not use SRFI-13.  It is not a
performance issue either, I think; and maintainability is okay, too.

And, we can always change this without breaking the interface.

> You can also put srfi-13.c and srfi14.c into their own shared
> libraries, and then make libguile-srfi-srfi-13.la depend on
> libguile-srfi-srfi-14.la like this (untested)
> 
>     lib_LTLIBRARIES = libguile-srfi-srfi-13.la \
>                       libguile-srfi-srfi-13.la
> 
>     libguile_srfi_srfi_13_la_SOURCES = srfi-13.x srfi-13.c
>     libguile_srfi_srfi_13_la_LDFLAGS = -version-info 0:0 -export-dynamic
>     libguile_srfi_srfi_13_la_LIBADD = libguile-srfi-srfi-14.la
> 
>     libguile_srfi_srfi_13_la_SOURCES = srfi-14.x srfi-14.c
>     libguile_srfi_srfi_13_la_LDFLAGS = -version-info 0:0 -export-dynamic
> 
> I'm not sure if that will be an improvement, though.

I don't think it is, but maybe I am missing something.  I propose not
to change this now and see if it turns out to be a problem.  I'll keep
this in mind, though.

Regards,
  'martin