Re: PHP to GUILE

[Thien-Thi Nguyen]

   From: Vorfeed Canal <address@hidden>
   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