Re: Text collation

[Rob Browning <rlb@defaultvalue.org>]

ludovic.courtes@laas.fr (Ludovic Courtès) writes:

> I don't think this is actually the case: there are currently 4
> shared libraries in the `srfi' directory, but none of them is
> documented in the manual and the C functions they export are not
> mentioned either (that's what I meant by "practically preclude":
> it's technically possible to use them but it's not documented).

Actually, in general, the SRFI scm_* functions are intended for public
use.  If not, then all of the relevant scm_* functions would/should
have been named scm_i_*.

Also, you definitely can't judge by the presence or lack of
documentation.  Guile's documentation has often taken a while to catch
up with the code.

(BTW, does documentation snarfing work right for C functions in
libraries outside libguile?  If not, then that's just a bug.)

> I would expect it to be done on purpose: For instance, the contents
> of `libguile-srfi-srfi-1' changed noticeably as some functions were
> rewritten in C and this is not something we want users to be aware
> of.

Note that when Marius moved the SRFI-13 and SRFI-14 functions to
libguile, he still kept the C library for backward compatibility.  I
believe this was specifically so that people who were already using
those functions wouldn't be affected.

> Yes, I'm open to that if we consider it a better option than having
> another shared lib.
>
> The issue, IMO, is that this is not very "scalable" either: we still
> end up adding one function call in `scm_i_init_guile ()' that
> systematically gets in the way.

I'm actually not sure which (of the discussed approaches) I think is
best.  I suppose first we'd need to consider the extent to which we
want to move toward a more modular ice-9 (more modular core), and then
determine how we might want to implement that modularity.

> Right.  What I had in mind was to have, say, `(dynamic-link)' (with
> no arguments) translate to `lt_dlopen (NULL)', so that we could
> access symbols contained within the executable.  Now, I'm not sure
> this would work in all cases, for instance when the executable is
> not `guile' itself.

Well, if we wanted to take this approach, and if lt_dlopen(NULL)
wouldn't do what was intended, perhaps there is some other way to
accomplish the same thing (i.e. to make sure you get the current
libguile.so), but I don't know offhand.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel