Re: PHP to GUILE

[Vorfeed Canal]

On 9/27/05, Thien-Thi Nguyen <address@hidden> wrote:
>
>    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).
>
I *DO* comprehend the need for something like this "in the bright
future" (after all translators must allow guile to use modules written
in list or TCL). But today... for just two possibilities (C glue code
and scheme sources) they look like much and too little in the same
time. Too much: we have two distinct things - stand-alone scheme
modules and non-stand-alone C glue code (:autoload is deprecated,
rememeber?). Plus C glue code is architecture-dependent (thus must be
in /usr/lib somewhere) while scheme code is not (so it must go in
/usr/share somewhere). Too little: there are no supports for
translators anyway (or I'm wrong and it IS possible to write module in
Logo?).

So I think for today simple search over two distinct lists (one for
architecture-dependent glue code and one for architecture-independent
scheme modules) are the best solution. Later when we'll have
translators and everything may be module catalogs will be usefull, but
not today.

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

I *AM* aware. But I think that modules catalogs are overkill for what
is awailable today and not enough for what is really needed in the
future. Thus it's better to use simpler approach: less complexity and
more-or-less the same benefits. Once we'll have loadable translators
and everything related we'll need some more complex approach.

> the particular implementations supported are currently scheme code and shared 
> object
> libraries, the latter thanks to libtool support in runtime and methodology.
>
And scheme code and shared object libraries are different enough to
make lumping them together rather impractical, while list and TCL are
not supported anyway - so what's the point ?

> 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 just want a way to keep all files related to some-big-project in
/usr/{lib,share}/same-big-project (unlike mess xchat-guile) and all
files related to guile x.y.z in /usr/{lib,share}/guile-something -
that's all. I do not think it's good idea to change the path on the
fly too often - more like part of initial setup + small extra (for
emergencies).

> 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.
>
To be frank the main part of doc is not even module system
specification and/or something like this but answer on simple question
WHY?. Why guile 1.4.1.1xx was ever developed ? Why parts of it are not
included in later versions of guile (yes, I know it's unofficial - yet
GNU Emacs does include some reimplemented extensions from XEmacs, so
it's not THE reason). I was unable to find this in documentation (or
better yet on site) so I was sure guile 1.4.1.106 is just bugfix
release for modern compilers.

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

It's my problem, right. Since guile 1.4 does not support some features
I want/need (GOOPS and pthreads are major ones) I can not use nice
things from your 1.4.1.1xx releases.