This is the mail archive of the guile@cygnus.com mailing list for the guile project.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
"merry::satchell"@hermes.dra.hmg.gb writes:
> Guile expects to find modules in its search path; as I understand
> things some of this is hard coded in c, and some defined in
> boot-9. Is there a more general abstraction to be had, as loading a
> file from a search path is needed by many programmes.
Two things come to mind. First, I like slib's notion of a vicinity,
i.e. you can create a vicinity, and then provide the vicinity to load
primitives, so that the path search is not done repeatedly. This is a
very clean way to avoid dozens of useless stat system calls, which can
be expensive across NFS or other distributed file systems.
(define guile-vicinity
(make-vicinity
(pathname (open-file-from-path "ice-9/boot-9.scm" %load-path))))
Then subsequent module loads can use a different load procedure, that
takes a vicinity as an argument, and avoid the path search:
I.e.
(use-modules (ice-9 regex))
could be a macro that expands into:
(load-module-vicinity guile-vicinity "ice-9/regex.scm")
And no path searching would be required.
Second, it might be worthwhile to examine the CL pathname abstraction,
because they have developed a very general system for locating files
on the file system. Note the experience of Emacs: not having a
pathname abstraction makes porting the system to other OS's difficult,
or at best users of the other systems must work with Unix conventions
in mind, which is a loser. If guile is to become ubiquitous, it would
be good to get these things right.
(Ducks from hail of rotten vegetables thrown due to positive CL
reference).
-russ
--
"It's like a love-hate relationship, without the love."
-- Jamie Zawinski, consummate UNIX hater, on Linux