Re: PHP to GUILE

[Thien-Thi Nguyen <ttn@glug.org>]

   From: Vorfeed Canal <vorfeed.canal@gmail.com>
   Date: Tue, 27 Sep 2005 14:11:47 +0400

   Too much: we have two distinct things - stand-alone scheme modules
   and non-stand-alone C glue code (:autoload is deprecated,
   rememeber?).

i'm afraid i can't share in this "we".  i use "standalone" shared object
libraries in cron-walk (part of ttn-do)[1], and in other places, all the
time, and guile 1.4.x does not deprecate #:autoload (as far as i can
tell).  for example (from cron-walk), the module `(database tmpfile)'
has this entry in ~/local/lib/guile/1.4.1.106/.module-catalog:

 ((database tmpfile)
  scm_init_module
  "scm_init_database_tmpfile_module"
  () . "/home/ttn/local/lib/guile/1.4.1.106/database/tmpfile.so.0.0.0")

when evaluating `(use-modules (database tmpfile))', there is exactly one
filesystem access, the dlopen of the tmpfile.so.0.0.0; "wrapper" scheme
code is not necessary.

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

all modules distributed w/ guile 1.4.x are installed in arch-dependent
dirs, in anticipation of the eventuality of scheme->sofile compilation,
thus sidestepping this problem.  the point is, wherever you decide
additional modules should go, it's enough to update the module catalog
so that guile can find it.  this supports local policy, which is one of
our shared concerns.

   Too little: there are no supports for translators anyway
   (or I'm wrong and it IS possible to write module in Logo?).

here is the entry for module (ice-9 q), in the same module catalog:

 ((ice-9 q)
  . "/home/ttn/local/lib/guile/1.4.1.106/ice-9/q.scm")

you can see that its form differs from that of (database tmpfile).
essentially, a module's "implementation type" is one of the pieces of
metadata that is encoded in the module catalog.  this means that the
system is ready to support other types.  however, i will concede that
presently, the actual load operation (`load' vs `dlopen') to be used for
any particular implementation type is not yet specifiable.  so i agree
halfly.

   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.

is it not better to eliminate (or reduce) search?  why use find(1) when
you have locate(1)?

   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 user pov sees no complexity:
(use-modules (ice-9 q) (database tmpfile))

complexity in implementation is another question.

   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 ?

in practice (from user pov), lumping them together works fine.

the point (in this case) is to advance the guile module system while
honoring the past (as opposed to spurning it), solving its problems by
generalizing the partial solutions (of the past) and then respecializing
them to apply to new domains.  when a problem is not yet solved, that's
an opportunity to hack.  obviously, there is still hack potential in
supporting logo (for example).

   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.

i'm still working on a writeup for these (very relevant) questions.  if
you're still around in spring/summer 2006 you'll probably see a post to
guile-user announcing it.  if not but you think you might be interested
anyway, let me know and i will cc you.

   It's my problem, right.

it is a problem/opportunity of the community and how it interacts.

   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.

ok, i will no longer suggest guile 1.4.x for your situation.  instead i
suggest looking at the parts of it that you like and adding them in some
way or another to your methodology.  see [2] for work in this vein.

thi



[1] http://www.glug.org/people/ttn/software/ttn-do/
    http://www.glug.org/people/ttn/software/ttn-do/scm-html/cron-walk.scm.html.gz

[2] http://www.glug.org/people/ttn/software/guile-sdl/GUILE-FIXES


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user