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

[Rob Browning]

Martin Grabmueller <address@hidden> writes:

> I had thought about just adding a directory `srfi' to the
> distribution, which contains the SRFI-13 and SRFI-14 modules I wrote
> and possibly others, and which installs the Scheme modules under
> 
> <prefix>/share/guile/1.4.1/srfi
>
> and the libraries under
> 
> <prefix>/lib
> 
> Then no changes to the core would be necessary and the modules could
> get loaded with (use-modules (srfi srfi-13)).

I, for one, would love to see that.

> [ maybe I should just do as I please, and then let the maintainers
>   throw out the useless parts??? ]

If you propose it on guile-devel and wait a bit, unless someone
complains, I'd say go ahead.  There's been some discussion about where
*else* we might want the srfi functions, but I think having them
available explicitly as (use-modules (srfi srfi-N)) will always make
sense, no matter what else we do.

> Which leads me to another problem: I think I'll have to change the
> name of the modules, now that SRFI-14 is in.  The problem is that
> SRFI-13 and SRFI-14 are not independent, as the string library uses
> character sets.  Is there a possibility to make this dependency work
> with compiled modules?
> 
> Or simpler: What happens when two Scheme modules load the same shared
> library and each shared library installs primitives?  Do they get
> defined twice, as two different procedures?

I suspect you get two different scheme functions pointing to the same
underlying C function, but I don't know that for sure.

If so, then to avoid that, presuming two dynamic-links of a shared
library share the same static variables (which is my current
understanding), then how about just putting all the common stuff in a
common lib and then doing something like this from each of your srfi
module files:

  (let ((common-lib (dynamic-link "libsomemodulecommon.so.5")))
    (dynamic-call "somemodule_define_comon_bits" common-lib)
    ...)

where somemodule_define_common_bits looked like this:

  static SCM common_func1 = SCM_BOOL_F;
  static SCM common_func2 = SCM_BOOL_F;

  void
  somemodule_common_bits()
  {
    static int initialized = 0;

    if(!initialized)
    {
       common_func1 = gh_new_procedure(...);
       common_func2 = gh_new_procedure(...);
       ...
       initialized = 1;
    } else {
       gh_define("common-func-1", common_func_1);
       gh_define("common-func-2", common_func_2);
    }
  }

etc.  Of course, this presumes that gh_define behaves properly with
modules, and I'm not sure it does.  You might need some other magic
there.

Also, do we need a scm_protect_object here for the funcs?  Is there
any way that the module bindings for the functions could ever be
dropped?

-- 
Rob Browning <address@hidden> PGP=E80E0D04F521A094 532B97F5D64E3930