Hi, Rob Browning <[EMAIL PROTECTED]> 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
