[EMAIL PROTECTED] (Ludovic Courtès) writes: > 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.
Yes. It would be nice to have a more comprehensive solution for documentation, one that can be used both internally and externally. > 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. ;-) I don't really disagree. In particular, I think this is something we should definitely consider as we examine R6RS. > 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'. I'm somewhat inclined to think that the scheme-side module is a good idea, though perhaps it begs more general organizational questions. I'm less certain about whether or not adding small shared library is a good idea. However, in both cases, I need to think a bit more. -- 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