Re: Text collation

[ludovic.courtes@laas.fr (Ludovic Courtès)]

Hi,

Rob Browning <rlb@defaultvalue.org> writes:

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

No, it doesn't work.  In the latest `guile-reader', I have a couple of
modules that do (part of) what the Awk script in `libguile' does:
parsing the output of `cpp -DSCM_MAGIC_SNARF'.  I'd be in favor of
integrating such an approach in Guile core eventually.

>> 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.

Personally, I would like Guile "core" to be much more modular than what
it is now.  I believe many things in what we call "Guile core" are there
just because we want them to be part of the "standard Guile library",
but they certainly to not comprise the "core" or "kernel" of Guile.  For
instance, I believe the Gettext-related functions ought to be
distributed with Guile core but as a separate module.  Same for
SRFI-1[43].  Not to mention the bits and pieces that are in `boot-9' and
that happen to be visible to everyone.  ;-)

Basically, the logical separation among the R5.91RS standard libraries
has a level of granularity that looks appropriate to me.

Now, whether each module should load its own shared library is a
different issue.  This may depend on the module characteristics: size,
usefulness, C programmability.  We also have to find a balance between
lazy initialization (with `dynamic-link') and systematic initialization.


Getting back to `(ice-9 i18n)': I'm strongly in favor of keeping this as
a module; I am more inclined to having it in a separate shared library
(because it's not useful to everyone) but I wouldn't mind having it in
`libguile.so'.

Thanks,
Ludovic.


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