From: Vorfeed Canal <[EMAIL PROTECTED]> Date: Mon, 26 Sep 2005 20:34:16 +0400
Hmm... And why "module catalogs" are superior ? I see one reason for their existence, but may be there are ones. For example I view this feature: "the actual placement of the file in the filesystem is decoupled from its module name" as DISadvantage... I mean: we need hierarchy of modules, we have perfect system to organize objects in hierarchy called "filesystem" why we'll ever want to replace it without very compelling reasons? i think module catalogs are superior because they address some of your concerns (which i recognize since similar thinking inspired the design and implementation of the module catalog system). perhaps you are not aware that module catalogs map module names (list of symbols like: (ice-9 q)) to module implementations, which are actually files in the filesystem? the particular implementations supported are currently scheme code and shared object libraries, the latter thanks to libtool support in runtime and methodology. iirc, in an earlier message you ask for user ability to specify things (at runtime). the decoupling mentioned is a clean way to effect that. i will augment the docs to emphasize that the module catalog system does not replace guile's historic resolution process (the end result of which is always some file on the filesystem), but simply formalizes it (a bit) and extends it (a bit) in a backward- and (i hope) upward-compatible way. thanks for showing me how the docs can cause misunderstanding. The biggest problem with this mechanism is that it's unsupported by official version. if i can fix the problem of not having write privs, i can fix this problem as well (but not having write privs is no longer my problem). thi _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user
